事故复盘

与其自己在黑暗中摸索，不如来看看前人走过的弯路。这里记录了真实项目中的失败教训，帮助你提前规避风险。

严重程度

显示 11 / 11 条

项目在自己电脑上运行得很好，于是把 localhost 链接当作正式网址发了出去。直到演示的那一刻，才发现别人根本打不开——因为这个地址从来就只在自己的电脑上有效。

一个在本地开发环境中运行完美的应用，部署到线上服务器后立刻崩溃。排查后发现，本地和服务器之间存在多处环境差异——Node.js 版本不同、环境变量缺失、某个依赖的行为在不同操作系统上不一致。

包含重要资产的私密密钥意外上传到了公开代码仓库，几分钟内就被自动扫描程序抓取并盗用，产生了巨额账单。

一个商业产品中使用了带有严格开源许可协议的代码库。该协议要求任何使用了它的项目都必须同样开源。产品发布后，原作者发现了这一违规行为，发来了法律函件要求整改。

在没有使用版本管理工具的情况下，AI 的一次大规模修改把原本能运行的代码改崩了。由于没有任何历史记录可以回退，所有之前的工作成果彻底丢失，只能从零开始。

在安装依赖时，一个包名和知名库仅有一个字母之差的仿冒包被安装进了项目中。这个包表面上功能正常，但在后台悄悄读取了项目中的环境变量（包括 API 密钥），并将它们发送到了攻击者的服务器。

应用的数据库将用户密码以明文形式直接存储。当数据库因安全漏洞被攻击者获取后，所有用户的密码一览无余——攻击者无需任何破解，直接就能登录每一个用户的账号。

代码中存在一个未被发现的死循环，在夜间不断调用付费的云函数接口。由于没有设置用量上限或预算告警，调用持续了整整一夜。第二天早上，账户上已经累积了数千美元的费用。

一个运行了数月的应用突然无法访问。排查后发现，托管数据库的服务出了故障，数据库中的所有数据不可恢复。由于从未设置过任何备份机制，数月积累的用户数据、内容和配置全部永久丢失。

一个运行了半年的项目，在尝试添加一个看似简单的新功能时，修改了一处代码后引发了连锁反应——三个原本正常的功能同时出现问题。开发者试图修复，却发现代码已经复杂到完全无法理解，修一个问题就冒出两个新问题。最终不得不放弃现有代码，从零开始重建。

开发者完全信任 AI 给出的技术方案，没有做任何验证就直接部署上线。上线后发现：用户认证逻辑存在漏洞，任何人可以绕过登录访问其他用户的数据；同时，AI 选择的一个技术方案在数据量稍大时就出现严重的性能问题，页面加载时间超过 30 秒。