全栈开发踩坑实录：我犯过的错和学到的教训？

去年夏天的一个凌晨，我盯着屏幕上那个红色的 500 错误，手指悬在键盘上发抖。闪仓进销存的第一个付费用户——一家做外贸的小公司——刚用了三天就崩了。原因是我的数据库设计有个致命缺陷：订单表没有做分表，而用户的订单量在促销期间暴涨，直接撑爆了单表容量。那天晚上我一边改代码一边想：我一个全栈开发者，怎么会犯这种低级错误？

TL;DR 我踩过最大的坑是自以为技术牛逼就忽视基本功。数据库设计翻车、过度工程化、安全漏洞、忽略测试——这些错我都犯过。但每个坑都让我变得更清醒。今天聊聊我的踩坑实录，希望能帮你少走弯路。

为什么数据库设计会成为我的噩梦？

因为我太自信了，以为单表就能搞定一切。

做闪仓进销存第一个版本时，我图省事，把所有订单都塞进一张表。当时想的是：中小企业的订单量能有多大？结果用户做促销活动，一天就产生了 10 万条订单记录，加上之前的存量，表里很快有了 200 万行数据。查询开始变慢，最后直接超时。

那周我基本没睡，连夜做分表方案。后来我用了按时间分表 + 读写分离，性能才算稳住。这个教训让我明白：设计阶段多想一步，能省掉后面无数个不眠夜。 ^[1]

过度工程化是怎么浪费我三个月的？

因为我总想用最酷的技术，而不是最合适的技术。

刚开始做闪仓时，我一心想上微服务。Spring Cloud、Kubernetes、消息队列……一个独立开发者，硬要搞大厂那套。结果光搭建基础设施就花了一个月，还没写一行业务代码。后来我发现，对于初期 SaaS 产品，单体应用 + 简单的水平扩展完全够用。

Stack Overflow 2024 开发者调查显示，超过 60% 的独立开发者使用单体架构，而微服务更多是团队和规模化的选择^[2]。我硬是把简单问题复杂化，白白浪费了三个月。现在回头看，**技术选型的核心不是炫技，而是解决实际问题。

安全漏洞是怎么被用户发现的？

因为我太相信自己的代码了，没有做充分的安全测试。

闪仓进销存上线后，有个用户给我发邮件说：“你的 API 好像可以直接访问其他用户的数据。”我冷汗一下就下来了。检查后发现，我的多租户隔离只在前端做了，后端接口居然没有校验租户 ID。这意味着只要知道别人的 ID，就能看到他们的订单和库存。

GitHub 2024 年的报告指出，超过 40% 的 SaaS 漏洞源于身份验证和授权问题^[3]。我差点就成了这个统计数据的一部分。还好用户是善意的，帮我发现了问题。从那以后，我在每个后端接口都加了租户 ID 校验，还做了定期安全审计。**安全不是功能，是底线。

忽视测试让我付出了什么代价？

代价是连续两周凌晨三点被报警短信吵醒。

起初我觉得，一个人开发，写测试太浪费时间。结果每次上线都提心吊胆，怕改个样式把核心逻辑搞崩。有一次我改了个库存扣减的逻辑，没写单元测试，结果上线后库存数据全乱了。用户打电话来骂，我花了两天手动修复数据。

后来我学了 TDD（测试驱动开发），虽然一开始觉得慢，但长期看反而省时间。现在闪仓进销存有 300+ 个单元测试和集成测试，覆盖率超过 70%。测试不是成本，是保险。 ^[4]## 从这些坑里，我学到了什么？

踩过这些坑后，我学会了一件事：承认自己会犯错，是成长的第一步。

• 数据库设计：一开始就考虑数据量和扩展性，别偷懒
• 技术选型：用最合适的，不是最酷的
• 安全：永远假设你的代码有漏洞，然后去验证
• 测试：写测试不是浪费时间，是给自己买保险

现在每次做决策，我都会问自己：三个月后的我会感谢现在的选择，还是会骂我傻逼？这个简单的问题，帮我避开了很多坑。最后借用尼采的一句话：“凡不能毁灭我的，必使我更强大。”每个 bug、每个设计失误，都让我成为一个更好的开发者。

---

参考来源

1. Stack Overflow 2024 开发者调查 — 关于架构选择的统计数据
2. Stack Overflow 2024 开发者调查 — 独立开发者架构选择数据
3. GitHub Octoverse 2024 报告 — SaaS 漏洞中身份验证和授权问题的占比
4. GitHub Octoverse 2024 报告 — 测试覆盖率与软件质量的关系