Vibe Coding 的你，有没有这种经历？

都用 AI 编程，你做了一个程序，但是程序员看了一眼说：「你做的那叫 Demo，离企业级还差得远嘞。」

这句话不是嘲讽，是事实。

事实归事实，不代表你要怕它。

不是你做的东西不行。真正的问题是：没人告诉你，企业级到底比 Demo 多了什么。你只知道它「复杂」，但不知道复杂在哪，所以就只能焦虑。

这篇文章把「多出来的那些」一个个讲清楚。看完你会发现两件事：一是 Demo 没那么弱，二是企业级没那么玄。

就拿新手基本都做过的记账工具举个例子（日记功能也差不多）。打开页面，输入金额，选分类，点保存，列表里多一条。

这就是 Demo。

或者你想做个计算器，一个 Python 脚本就够了，前端、后端、数据库都不需要。

这些不是 bug，是 Demo 本来就没打算处理这些。

程序员说的「企业级」，不是功能更多，是任何情况下都不能崩——稳！

下面这些，是 Demo 不需要管、但企业级必须管的东西。

Demo 里，输入是你自己填的，你不会害自己。企业级里，输入来自互联网上的任何人。

你在页面上写了「金额必须是数字」，用户按 F12 打开开发者工具，把这段 JS 改掉，就能提交任何东西。或者干脆不用你的页面，直接用 Postman 调你的接口，前端的校验就失效了。

所以真正的校验，必须在后端再做一遍。

假设你写了一段代码：

正常输入时没问题。但如果用户把 name 填成：

你的 SQL 就变成了：

'1'='1' 永远成立，这条语句会返回所有用户。

原本你只想查一个人，结果把整张表交了出去。

这就是 SQL 注入。攻击者可以用它拖走整个数据库、篡改数据、甚至通过数据库控制整台服务器。

互联网上有无数扫描机器人，24 小时在找这种漏洞。你的网站一上线，几小时内就会被扫到。

怎么防：参数化查询。

驱动会把 name 当成一个「值」来处理，不管里面有什么字符，都不会被当成 SQL 语句的一部分。

用 ORM（比如 SQLAlchemy）天然就是参数化的，所以推荐用 ORM，少手写 SQL。

不要相信任何来自用户的东西，哪怕它已经存在你自己的数据库里。

这里反直觉的地方是：框架默认已经帮你防住了，出事往往是你自己把防护关掉的。

Vue 里 {{ comment }} 默认就会转义，<script> 会变成普通文字，根本不会执行。也就是说，你什么都不做，它就是安全的。

出事的场景只有一个：你为了显示富文本、显示好看的格式，主动用了 v-html，亲手把门打开了。

用户在评论区输入这样一段「评论」：

你的页面用 v-html 一渲染，这段脚本就在所有访问者的浏览器里执行，把所有访问者的 cookie 发给攻击者。

最危险的地方在于：用户以为是你的网站，实际上是攻击者在操作。攻击者自己没事，受害的是每一个来看你网站的人。

还有一个更容易忽略的变种：存储型 XSS。很多人觉得「数据是从我数据库里读出来的，安全」。但数据库里的数据是用户提交进来的。用户提交了恶意脚本，你存进了数据库，再渲染出来——每个访问者都会中招。

防范办法：永远不要用 v-html 渲染用户输入，用默认的 {{ }}（它会自动转义）。如果必须渲染富文本，用 DOMPurify 过滤。

Demo 只有你一个人用，不存在这个问题。

企业级要考虑：同一时刻，有两个人操作同一条数据，会发生什么？

最经典的例子是库存超卖。假设商品只剩 1 件，用户 A 和用户 B 同时下单：

结果卖出去 2 件，但你只有 1 件。

这不是「万一」，是一定会发生，只是概率问题。防范靠数据库事务和锁。

还有一个词你会反复听到：幂等。

用户点了「支付」，网络卡了一下，他没看到反应，又点了一次。如果你的接口不处理这种情况，用户就被扣了两次钱。

幂等的做法：每次请求带一个唯一的「幂等键」，服务器看到重复的键就返回上次的结果，不重复执行。

很多人以为是一回事，其实不是。

认证（Authentication）= 你是谁。 比如登录，验证用户名密码，确认「你是张三」。

授权（Authorization）= 你能干什么。 张三登录了，但他能不能删别人的帖子？能不能看财务报表？这就是授权。

Demo 里可能就一个用户，谈不上授权。企业级里通常有角色系统：

这就是 RBAC 权限模型（Role-Based Access Control，基于角色的访问控制）。

另一个关键问题：登录状态怎么保持？ 常见两种方案：

各有取舍，企业级要选一个并处理它的副作用（比如 JWT 的「无法吊销」问题）。

Demo 里，一切都在你电脑上，大不了重新改。

企业级里，所有外部依赖都可能随时挂：数据库可能连接超时，第三方 API 可能返回 500，网络可能抖动，对方服务可能完全没响应。你不能假设它们总是成功。

企业级要处理这些：

这些词（超时、重试、熔断、降级）听着高深，其实思路很简单：假设一切都会坏，然后想好坏了怎么办。

Demo 出错了，你看终端打印。企业级出错了，你可能连哪里出错都不知道，因为请求经过了好几个服务。

可观测性有三件套：

为什么要这么复杂？因为线上环境不像你本地。你本地打断点就能知道一切，线上是黑盒，只能靠这三样东西推断。

Demo 里，数据存进 SQLite 就完事了。

企业级里，数据要经历：创建 → 使用 → 备份 → 迁移 → 归档 → 删除。每个阶段都有坑。

迁移：你需要给用户表加一个字段。SQLite 里 ALTER TABLE 就行，但线上不能直接改，因为：

所以企业级要用数据库迁移工具（Alembic、Flyway），每次改表都是一次「版本化」的操作，可以前进也可以后退。

备份：数据丢了怎么办？定时全量备份 + 增量备份，而且要定期演练恢复。备份了不能恢复，等于没备份。

删除：用户注销了，数据怎么删？《个人信息保护法》和 GDPR 要求「被遗忘权」。你不能只标记删除，得真删、可验证地删。

Demo 是你本地跑着，关掉就没了。企业级部署要考虑：

回滚这件事比你想的复杂。 代码回滚很容易，git revert 就行。但如果新版本改了数据库结构，回滚代码的时候数据库已经变了，旧代码可能跑不起来。

所以数据库变更要设计成向前兼容：新字段先加着不用，等所有代码都升级完了再启用。这叫「扩展-迁移-收缩」模式。

这一条很少有人提，但很现实。

Demo 几乎是 0 成本。企业级是每月都在烧钱：

所以「要不要上企业级」不光是技术问题，也是成本问题。 很多独立开发者做的东西，用一台 200 块的云服务器就够了。硬上企业级架构，反而是浪费。

讲了这么多「企业级要考虑什么」，容易让人产生一个错觉：企业级 = 完美。

不是的。

企业级应用照样有 bug，照样出事，照样天天更新。

你手机上任何一个 App，每周都在发新版本。那不是因为它「做得不好」，是因为开发本身就是一个不断发现问题、找应对方法的过程。

缝缝补补是常态，不是失败的证据。 企业级和 Demo 的区别，不是「一个完美一个不完美」，而是：

锅和材料就是代码本身。if、for、函数、数据库查询——这些你写 Demo 用什么，企业级也是用什么。代码没变，变的是背后考虑了多少东西。

当成生意做，考虑的东西就更多。 这不是能力问题，是场景问题。

所以别神化企业级。它只是「把这件事当成生意来做」的产物。它不完美，它也在迭代，它也在缝缝补补。

只不过它缝补的时候，要同时考虑一百个人在等着吃饭。

自己做 Demo，没那么多讲究，能跑就行，完全可以眉毛胡子一把抓，哪里不对改哪里。

但是企业级不行，服务的客户多、升级多、改动多，就需要采取分离的架构。这样一来，前端改样式不影响后端，后端升级不影响前端，更加灵活，不用为了一个小问题大改代码、重新部署。

前端 = 你看到和操作的部分。 按钮、表单、列表、弹窗。负责展示、交互、收集输入、展示结果。不负责算。

后端 = 你看不到、但真正干活的部分。 数据存哪、怎么存、有没有校验、谁能看——都在后端。

API = 前端和后端之间的合同。 它不是「服务员传菜」，是「合同」。合同规定了：

合同一旦定了，前端和后端就可以独立开发，互不干扰。

前后端分离就是分工。 前端改样式不影响后端，后端升级不影响前端，想做 App 直接复用同一套后端。

说了这么多，不是要吓你。自己用的工具，Demo 完全够了。

不用考虑并发——就你一个人用。不用考虑权限——就你自己看。不用考虑部署——本地跑着就行。不用考虑监控——挂了你自己知道。

能，就够了。不能，改到能。改完还不行，换个思路。

手搓吧，风险可控就行。 什么叫风险可控：

在这个范围内，随便搓。搓坏了删掉重来，搓崩了重启一下。

只要学，肯定有收获。 搞明白 print 和 return 的区别，明天就能看懂 AI 为什么这里用 return 那里用 print。搞明白前端后端的区别，明天就能跟程序员聊到一块去。搞明白 Demo 和企业级的差距，明天就知道该学什么、不该焦虑什么。

代码没变，变的是边界。

程序员说「你做的是 Demo」，不是嘲讽，是事实。

但 Demo 不丢人。每一个企业级应用，都是从 Demo 开始的。

自己用，Demo 就是终点。给别人用，一步一步往前走。

别再被「企业级」吓住了。它复杂，但它不神秘。它也不完美，它也在缝缝补补。