网站项目的工作流程长沙公司做网站的价格

张

张建站

2026/7/6 23:13:54

10分钟阅读

网站项目的工作流程,长沙公司做网站的价格,做海报用什么网站,网站备案账号是什么你是否在某个项目里被这个灵魂拷问击中过#xff1a;为什么别人的API响应快到飞起#xff0c;我的却慢得让人想砸键盘#xff1f;这背后往往不是代码逻辑的问题#xff0c;而是一个你可能没有好好思考过的决策——选择什么样的数据库#xff0c;以及用什么方式…你是否在某个项目里被这个灵魂拷问击中过为什么别人的API响应快到飞起我的却慢得让人想砸键盘这背后往往不是代码逻辑的问题而是一个你可能没有好好思考过的决策——选择什么样的数据库以及用什么方式去连接它。很多初学者拿到需求时看到数据就直接上MongoDB啊JSON格式多省事啊或者看到关系就无脑PostgreSQL这是大厂标配。但这样做的代价在系统真正承载数据压力时才会显现出来。今天我想从源码和实战角度为你拆解Node.js 连接 PostgreSQL 和 MongoDB 的底层原理帮你理解为什么选择不同的库、不同的连接方式会导致完全不同的性能表现一个比喻理解关系数据库 vs 文档数据库在开始写代码前我想用一个日常的比喻来帮助你理解两种数据库的本质差异。PostgreSQL关系型数据库就像一个严格的档案室每个文件柜表都有明确的分类标准Schema每个抽屉字段都必须放特定类型的信息不同文件柜之间有清晰的索引和连接方式外键关系当你要找某个信息时系统能快速定位到具体位置MongoDB文档数据库就像一个灵活的收藏盒每个盒子集合可以装各种形状、大小的物品文档同一个盒子里的物品形态可以完全不同动态Schema物品之间的关系不由系统强制而由你的应用逻辑维护当你要找东西时速度取决于你建没建好索引理解了这个差异你就明白为什么选择数据库需要匹配你的实际业务模型。PostgreSQL严谨的数据守护者为什么选PostgreSQL我先坦白PostgreSQL 并不是最快的选择但它是最稳的选择。这是为什么大厂生产环境中PostgreSQL 的使用率一直这么高的原因。PostgreSQL 的核心优势ACID 保证每一次事务都像是在签合同不能反悔。这对金融、支付、库存等对数据一致性有严格要求的系统来说是生命线。复杂查询能力JOIN、复杂的 WHERE 条件、聚合函数……这些运算都由数据库来承担而不是拉到应用层处理。这是减轻服务器压力的关键。成熟的优化PostgreSQL 有接近 30 年的发展历史查询规划器能在你写出烂SQL的时候仍然想办法给你一个不至于太糟糕的执行计划。Node.js 连接 PostgreSQL深入pg库让我们来看看pg这个库是怎么工作的。安装npm install pg基础连接代码// db.js const { Client } require(pg); const client new Client({ user: your_username, host: localhost, database: testdb, password: your_password, port: 5432, }); client.connect() .then(() console.log(已连接到 PostgreSQL)) .catch(err console.error(连接出错:, err.stack)); module.exports client;但这里有个问题——代码看起来简单实际上隐藏了很多细节。让我帮你理解一下背后发生了什么当你调用client.connect()时Node.js 会建立一个 TCP 连接到 PostgreSQL 服务器发送认证信息用户名、密码PostgreSQL 验证你的身份分配一个连接资源返回一个准备好接收查询的连接对象你的应用 TCP连接 PostgreSQL 服务器 |--------建立-------| |--------认证-------| |-------响应--------| | 准备好发送SQL |这个过程会花费几毫秒到几十毫秒的时间。如果你每次查询都重新建立连接那就悲剧了。连接池避免连接炸裂实际项目中我们应该用连接池而不是单独的 Client// db.js - 使用连接池推荐 const { Pool } require(pg); const pool new Pool({ user: your_username, host: localhost, database: testdb, password: your_password, port: 5432, max: 20, // 最大连接数 idleTimeoutMillis: 30000, // 空闲连接30秒后关闭 connectionTimeoutMillis: 2000, // 获取连接超时2秒 }); // 使用 pool.query() 代替 client.query() module.exports pool;为什么需要连接池想象一下如果有 100 个请求同时到达你的服务器每个请求都要建立一个到 PostgreSQL 的连接。这意味着 PostgreSQL 要维护 100 个连接每个连接都占用内存和文件描述符。而实际上你的PostgreSQL 实例可能只有 20 个处理线程。连接池的做法是维护一个固定大小的连接队列。当请求来时从池里借一个连接用完了放回去。这样无论有多少请求数据库侧的压力是恒定的。请求 1 ——\ 请求 2 ——|- 连接池(max: 20) ——- PostgreSQL (20个处理线程) 请求 N ——/实战数据的CRUD操作现在让我们看看怎么真正地增删改查插入数据// 错误示范 ❌ - SQL注入的噩梦 const insertUser async (user) { const query INSERT INTO users(name, age) VALUES(${user.name}, ${user.age}); try { const res await pool.query(query); console.log(插入成功:, res.rows[0]); } catch (err) { console.error(插入失败:, err); } }; // 如果用户输入了user.name Robert); DROP TABLE users; -- // 你的整个 users 表就没了。这不是危言耸听是真实的灾难。正确的做法 ✅ - 使用参数化查询const insertUser async (user) { const query { text: INSERT INTO users(name, age) VALUES($1, $2) RETURNING *, values: [user.name, user.age], }; try { const res await pool.query(query); console.log(插入成功:, res.rows[0]); return res.rows[0]; } catch (err) { console.error(插入失败:, err.stack); } }; await insertUser({ name: 张三, age: 28 });为什么要用参数化查询参数化查询的工作流程是这样的1. 你发送 SQL 模板INSERT INTO users(name, age) VALUES($1, $2) 2. PostgreSQL 预先编译这个模板检查语法和权限 3. 你分别发送数据[张三, 28] 4. PostgreSQL 把数据当作数据绝对不会作为 SQL 命令执行这样即使用户输入包含特殊字符或 SQL 关键词也只会被当作字面值处理。查询数据// 获取所有用户 const getUsers async () { try { const res await pool.query(SELECT * FROM users); return res.rows; } catch (err) { console.error(查询失败:, err); } }; // 获取特定用户带条件 const getUserById async (id) { try { const res await pool.query(SELECT * FROM users WHERE id $1, [id]); return res.rows[0]; } catch (err) { console.error(查询失败:, err); } }; // 带复杂条件的查询 const searchUsers async (ageMin, ageMax) { try { const res await pool.query( SELECT id, name, age FROM users WHERE age BETWEEN $1 AND $2 ORDER BY age DESC, [ageMin, ageMax] ); return res.rows; } catch (err) { console.error(查询失败:, err); } };更新和删除const updateUser async (id, updates) { const { name, age } updates; try { const res await pool.query( UPDATE users SET name $1, age $2 WHERE id $3 RETURNING *, [name, age, id] ); return res.rows[0]; } catch (err) { console.error(更新失败:, err); } }; const deleteUser async (id) { try { const res await pool.query( DELETE FROM users WHERE id $1 RETURNING *, [id] ); return res.rows[0]; } catch (err) { console.error(删除失败:, err); } };MongoDB灵活的数据冒险家为什么选MongoDB坦白说MongoDB 在以下场景最有魅力数据结构不确定你在快速迭代产品字段会经常变化。用 PostgreSQL 的话每次都要跑 migration太烦了。嵌套数据结构如果你的数据本身就是树形或多层次的比如评论系统MongoDB 的文档模型会让代码更直观。水平扩展MongoDB 的分片机制相对简单如果你需要把数据分散到多个服务器MongoDB 可能比 PostgreSQL 更容易上手。但是——别被这些优势迷惑。MongoDB 的代价是你失去了数据库层面的严格保证很多事情得靠应用代码来保证。Node.js 连接 MongoDB使用 Mongoosenpm install mongoose基础连接const mongoose require(mongoose); mongoose.connect(mongodb://localhost:27017/testdb, { useNewUrlParser: true, useUnifiedTopology: true, }) .then(() console.log(已连接到 MongoDB)) .catch(err console.error(连接出错:, err));但这里也有个问题——Mongoose 是一个 ODM对象文档映射库它在 MongoDB 上面又加了一层。你的应用代码 | Mongoose定义Schema、验证、钩子 | MongoDB 驱动实际的网络通信 | MongoDB 服务器这一层的好处是你得到了某种程度的数据结构保证坏处是多一层抽象会有额外的开销。定义 Schema 和 Model// user.model.js const mongoose require(mongoose); const userSchema new mongoose.Schema({ name: { type: String, required: true, // 必填 trim: true, // 自动去除前后空格 maxlength: 50, // 最大长度 }, age: { type: Number, min: 0, // 最小值 max: 120, // 最大值 }, email: { type: String, unique: true, // 唯一性约束 lowercase: true, }, createdAt: { type: Date, default: Date.now, // 默认值 }, role: { type: String, enum: [user, admin], // 枚举值 default: user, }, }); // 创建索引加快查询速度 userSchema.index({ email: 1 }); userSchema.index({ name: 1, age: -1 }); const User mongoose.model(User, userSchema); module.exports User;**Schema 就是你对数据结构的承诺**。定义了以后Mongoose 会在数据进入之前先验证一遍。但要注意这个验证只在应用层发生MongoDB 服务器本身并不知道这些规则。如果有其他应用直接连到 MongoDB它可以绕过这些验证。这就是为什么有些人说 MongoDB 没有真正的 Schema。实战使用 Mongoose 进行 CRUD创建插入// 错误示范 ❌ const insertUser async (userData) { try { const user new User(userData); await user.save(); console.log(插入成功:, user); return user; } catch (err) { // 会捕捉到各种验证错误、唯一性冲突等 console.error(插入失败:, err.message); } }; // 问题如果字段不合法会抛异常。没有错误处理很容易让应用崩溃。 // 正确的做法 ✅ const insertUser async (userData) { try { const user new User(userData); const savedUser await user.save(); return { success: true, data: savedUser }; } catch (err) { if (err.code 11000) { // 唯一性冲突 return { success: false, error: 该邮箱已被注册 }; } elseif (err.name ValidationError) { // 验证失败 return { success: false, error: err.message }; } return { success: false, error: 未知错误 }; } };查询// 获取所有用户 const getUsers async () { try { const users await User.find(); return users; } catch (err) { console.error(查询失败:, err); } }; // 查询特定用户 const getUserById async (id) { try { const user await User.findById(id); return user; } catch (err) { console.error(查询失败:, err); } }; // 带条件的查询Mongoose Query API 很强大 const searchUsers async (minAge, maxAge) { try { const users await User.find({ age: { $gte: minAge, $lte: maxAge } }).sort({ age: -1 }); return users; } catch (err) { console.error(查询失败:, err); } }; // 查询并投影只返回特定字段 const getUserEmails async () { try { const users await User.find({}, email name); // 只返回 email 和 name return users; } catch (err) { console.error(查询失败:, err); } }; // 复杂查询aggregation pipeline聚合管道 const getAgeStatistics async () { try { const stats await User.aggregate([ { $group: { _id: $role, avgAge: { $avg: $age }, count: { $sum: 1 }, } }, { $sort: { count: -1 } } ]); return stats; } catch (err) { console.error(聚合失败:, err); } };更新// 更新一个文档 const updateUser async (id, updates) { try { const user await User.findByIdAndUpdate( id, updates, { new: true, // 返回更新后的文档 runValidators: true// 更新时也要运行验证 } ); return user; } catch (err) { console.error(更新失败:, err); } }; // 更新多个文档 const updateMultipleUsers async (filter, updates) { try { const result await User.updateMany(filter, updates); return { modifiedCount: result.modifiedCount }; } catch (err) { console.error(批量更新失败:, err); } };删除// 删除单个 const deleteUser async (id) { try { const user await User.findByIdAndDelete(id); return user; } catch (err) { console.error(删除失败:, err); } }; // 删除多个 const deleteMultipleUsers async (filter) { try { const result await User.deleteMany(filter); return { deletedCount: result.deletedCount }; } catch (err) { console.error(批量删除失败:, err); } };对标对比何时选PostgreSQL何时选MongoDB让我做个实际的对比表格帮你做决策场景PostgreSQLMongoDB赢家理由电商订单系统✅✅✅⚠️PostgreSQL需要严格的事务保证订单和库存的关系复杂用户日志/分析⚠️✅✅✅MongoDB字段经常变化对一致性要求不高需要快速写入社交媒体内容✅✅✅MongoDB评论、回复的嵌套结构天然适合文档财务/支付✅✅✅❌PostgreSQL零容忍的一致性要求MongoDB 不够可靠内容管理系统✅✅✅MongoDBSchema 频繁变化MongoDB 灵活性高实时统计✅✅⚠️PostgreSQL复杂的 JOIN 和聚合PostgreSQL 更高效用户行为追踪⚠️✅✅✅MongoDB海量数据灵活Schema易于扩展实际场景从决策到实现场景构建一个博客系统一个典型的博客需要用户表账户、权限文章表内容、发布时间评论表与文章、用户关联用户(1) -----(N) 文章 | -----(N) 评论 -----(N) 用户用 PostgreSQL 的方案// 创建表SQL 层面 CREATE TABLE users ( id SERIAL PRIMARY KEY, username VARCHAR(50) UNIQUE NOT NULL, email VARCHAR(100) UNIQUE NOT NULL, created_at TIMESTAMP DEFAULT NOW() ); CREATE TABLE articles ( id SERIAL PRIMARY KEY, title VARCHAR(200) NOT NULL, content TEXT, author_id INTEGER REFERENCES users(id), created_at TIMESTAMP DEFAULT NOW() ); CREATE TABLE comments ( id SERIAL PRIMARY KEY, content TEXT NOT NULL, article_id INTEGER REFERENCES articles(id) ON DELETE CASCADE, author_id INTEGER REFERENCES users(id), created_at TIMESTAMP DEFAULT NOW() ); // 查询文章及其所有评论 SELECT a.*, json_agg( json_build_object( id, c.id, content, c.content, author, u.username, created_at, c.created_at ) ) as comments FROM articles a LEFT JOIN comments c ON a.id c.article_id LEFT JOIN users u ON c.author_id u.id WHERE a.id $1 GROUP BY a.id;用 MongoDB 的方案// 定义 Schema const articleSchema new mongoose.Schema({ title: String, content: String, author: { type: mongoose.Schema.Types.ObjectId, ref: User }, comments: [ { content: String, author: { type: mongoose.Schema.Types.ObjectId, ref: User }, createdAt: { type: Date, default: Date.now } } ], createdAt: { type: Date, default: Date.now } }); // 查询文章及其评论 const article await Article.findById(articleId) .populate(author, username) .populate(comments.author, username);对比分析数据完整性PostgreSQL 用外键强制关系MongoDB 靠应用代码维护。如果有 bugPostgreSQL 能救你MongoDB 就看天了。查询灵活性PostgreSQL 的 SQL 非常灵活可以做复杂的 JOINMongoDB 的 aggregation pipeline 也很强大但语法学习曲线陡峭。写入速度MongoDB 通常更快因为没有那么多验证开销。但这也意味着坏数据更容易混进去。扩展性如果数据量爆表数十亿级别PostgreSQL 需要仔细的分区策略MongoDB 的 sharding 相对开箱即用。深层次的选择标准1. 数据一致性的权衡PostgreSQL 的事务模型保证了 ACID原子性要么全部成功要么全部失败一致性数据始终满足定义的约束隔离性并发事务互不干扰持久性提交后数据永不丢失MongoDB 从 4.0 版本后也支持事务但只支持副本集不支持单机性能开销相对较大跨分片事务有严格限制如果你做的是支付、库存、转账等对数据完整性零容忍的系统PostgreSQL 是必选题。2. 查询模式PostgreSQL 优化器是经过数十年磨练的能处理复杂的 JOIN 和聚合。即使你写的 SQL 不是最优的它也能想办法给你一个不太差的执行计划。好的 SQL ──┐ ├─→ 查询优化器 ──→ 执行计划 ──→ 结果烂的 SQL ──┤ (PG) (可能还不错) │ └─→ 仍然能跑MongoDB 的查询优化相对简单主要靠你建索引的水平。3. 运维成本PostgreSQL需要理解 VACUUM、ANALYZE、Index 等概念需要监控 slow queries但整个系统相对稳定不容易出现诡异的数据不一致问题MongoDB学习曲线相对平缓但当出现 replica set 选举、oplog 堆积等问题时调试会很痛苦需要更频繁地处理数据重复、不一致的情况常见陷阱和优化技巧PostgreSQL 的常见陷阱陷阱 1N1 查询问题// ❌ 错误示范N1 查询 const articles await pool.query(SELECT * FROM articles); for (const article of articles.rows) { const comments await pool.query( SELECT * FROM comments WHERE article_id $1, [article.id] ); article.comments comments.rows; } // 结果1次获取所有文章 N次获取评论 N1 次查询 // ✅ 正确做法使用 JOIN 一次性获取 const result await pool.query( SELECT a.id, a.title, a.content, json_agg(json_build_object(id, c.id, content, c.content)) as comments FROM articles a LEFT JOIN comments c ON a.id c.article_id GROUP BY a.id );陷阱 2没建索引就直接查询// ❌ 没有索引百万级数据扫描会很慢 SELECT * FROM users WHERE email userexample.com; // ✅ 建索引 CREATE INDEX idx_users_email ON users(email);MongoDB 的常见陷阱陷阱 1数据重复和不一致// ❌ 坏主意在文档中冗余存储用户信息 const article { title: xxx, author: { id: 123, name: 张三, email: zhangsanxxx.com// 冗余 } }; // 当用户改名了你得更新所有包含这个用户信息的文章 // 如果有百万篇文章这个操作会很慢还可能更新不完整 // ✅ 正确做法只存储 ID查询时 populate const article { title: xxx, author: ObjectId(...) }; // 查询时 const article await Article.findById(id).populate(author);陷阱 2过度设计 Schema// ❌ 把本应分表的东西硬塞到一个文档里 const order { orderId: ..., orderDate: ..., items: [ { productId: ..., price: 100, ... }, // 可能有几百个 ], shippingAddress: { ... }, billingAddress: { ... }, // ... 还有很多很多字段 }; // 问题这个文档可能大到 16MB 的 MongoDB 限制 // 而且每次查询都得加载整个文档 // ✅ 分散数据 const order { orderId: ..., orderDate: ..., // 只存必要的字段 }; const orderItems { orderId: ..., items: [...] }; // 需要时分别查询性能基准测试真实对比让我基于常见场景做个粗略的性能对比操作PostgreSQLMongoDB备注简单插入 10万~500ms~300msMongoDB 快因为验证少带约束插入 10万~800ms~1000msPostgreSQL 约束多但优化好简单查询 (有索引)~5ms~5ms差不多复杂 JOIN (5张表)~50msN/APostgreSQL 专长聚合统计 (500万条)~200ms~300msPostgreSQL 稍快范围扫描 (无索引)~5000ms~6000ms都慢不要做核心结论简单操作上两者差异不大复杂查询上PostgreSQL 显著更优写入密集上MongoDB 略快维护成本上PostgreSQL 稳定性更高最后的思考你真的需要选一个吗很多大型系统其实是多数据库混用的应用层 | ├─→ PostgreSQL订单、库存、用户账户 - 需要事务 ├─→ MongoDB日志、用户行为追踪 - 灵活Schema ├─→ Redis缓存、会话 - 高速读写 └─→ Elasticsearch日志搜索 - 全文检索字节跳动、阿里这样的大厂就是这样做的。他们没有标准答案而是根据每个子系统的特点选择最合适的工具。总结和行动清单理论层面✅ PostgreSQL 严谨、可靠、复杂查询强 → 用于核心业务数据✅ MongoDB 灵活、快速、易扩展 → 用于日志、分析、快速迭代实战层面✅ PostgreSQL 用连接池不要每次都新建连接✅ MongoDB 用 Mongoose但理解它只是应用层的保障不是真正的强一致性✅ 参数化查询/Schema 验证 → 防止 SQL 注入和数据污染✅ 建立合理的索引 → 查询速度的天壤之别✅ 监控和告警 → 及时发现性能瓶颈选择清单选 PostgreSQL 如果数据一致性很重要支付、库存需要复杂的 JOIN 和事务数据关系明确Schema 相对稳定选 MongoDB 如果数据结构经常变化主要操作是 CRUD少复杂查询需要快速原型化和迭代FAQQ我应该先学 PostgreSQL 还是 MongoDBA建议先学 PostgreSQL。原因很简单SQL 是通用的PostgreSQL 会强制你理解数据结构和关系。掌握了这些学 MongoDB 会轻松得多。反过来就容易形成只会 NoSQL 的局限。Q可以同时用 PostgreSQL 和 MongoDB 吗A完全可以。在一个应用里用多个数据库是常见做法。比如用 PostgreSQL 存业务数据用 MongoDB 存日志用 Redis 做缓存。但要注意数据一致性问题——确保两个库的数据能同步或者有明确的 owner。Q连接池该设多大A一个经验法则是最大连接数 (核心数 × 2) 有效硬盘数。对于大多数 Node.js 应用20-50 个连接就足够了。超过 100 个通常说明架构有问题。QMongoDB 是不是都不安全AMongoDB 本身没问题是使用方式的问题。如果你严格遵循 schema 验证、参数化查询、建立约束MongoDB 也很安全。但容易放松警惕所以在关键业务上 PostgreSQL 是更保险的选择。Q什么时候应该考虑 sharding分片A当单个数据库实例无法承载时。但 sharding 会增加复杂度建议等到真的有问题了再做。过早的优化只会埋坑。对于 PostgreSQL通常用分表对于 MongoDB用自动 sharding。互动彩蛋如果你现在正在某个项目里纠结选 PostgreSQL 还是 MongoDB欢迎在评论区留言你的场景我很想看看大家都在做什么样的项目遇到了什么样的问题。你也可以分享这篇文章给你的同事相信这个思考维度会对他们的架构设计有所启发。如果想持续获得这样的硬核技术内容记得关注《前端达人》。我们定期产出 React、Node.js、浏览器原理等深度好文帮你从表面理解走向本质掌握。点赞 ✨、分享、推荐给朋友 ——这是对内容最好的鼓励也能帮助更多开发者做出更好的技术决策。下期见