500个用户，每天100万次数据库读取——当你的AI编程助手写的代码开始烧真钱，免费额度超支20倍只是开始。
这不是大厂架构师的技术分享，而是一个用AI工具独立开发游戏门户的工程师，在账单和性能双重暴击下的真实排查记录。他发现了三个藏在AI生成代码里的"性能地雷"，最后把月费压回免费档。
账单警报：从0到10美元的死亡曲线
事情是从一张平缓上升的账单开始的。
作者的游戏门户用户量在涨，Firebase Storage先跳出免费档。但真正的麻烦是Firestore——那个每天50,000次读取的免费阈值，被他的小系统干到了100万次/天，超了整整20倍。
月费涨到10美元，趋势还在向上。对独立项目来说，这不是钱的问题，是架构在报警。
更隐蔽的是性能体感。用户没抱怨，但HTTP服务的响应在变慢。作者意识到，AI助手当初搭的架子，可能藏着"小规模看不见、大规模要人命"的设计债。
三张图锁定元凶
他没有猜，而是铺了三条监控线。
账单报告先指认Firestore是唯一成本贡献者。钻进去看，某些集合的读取量和日活完全不成比例。
Firestore Query Insights（查询洞察）把火力集中到三个集合：用户资料（profile）、游戏完成记录（game completion）、高分榜（highscores）。
最后Google Cloud Observability（谷歌云可观测性）的HTTP API指标补刀——profile接口被调用太频繁，延迟还高；随机种子生成器（random seed generator）也一样。
三个数据源交叉验证，靶子清晰了：profile、游戏完成记录、随机种子，这三块吃掉大部分成本和延迟。
第一颗雷：用户看不见的N+1噩梦
最意外的发现来自一个后台任务。
nightly cleanup（夜间清理函数）是AI写的，用户从无感知。但代码里埋着经典的N+1查询模式——遍历所有profile文档，每个profile再跑子查询找旧游戏记录。
代码长这样：先`get()`拉取全部profile，然后for循环里每个profile单独查gameStats子集合。500个profile，哪怕只有30个有脏数据，也要执行501次读取。
作者算了笔账：~500个profile，~30个实际有旧数据，理论最低30次读取，实际干了501次。16倍的浪费。
修复方案是用集合组查询（collection group query）直接定位所有超期的gameStats，跳过profile这层遍历。一次查询替代501次，读取次数和实际脏数据量成正比。
第二颗雷：前端狂欢，后端买单
profile接口的高频调用，根子在前端。
AI助手写的客户端代码里，每次路由切换、每次页面刷新，都要重新拉profile。用户玩个游戏切几次页面，同样的数据被反复请求。
作者加了本地缓存层。profile数据在浏览器内存里驻留，配合合理的失效策略——用户主动更新才重新拉取，被动浏览走缓存。
HTTP调用次数断崖下跌。这不是算法优化，是减少无效通信。
第三颗雷：随机种子的伪需求
random seed generator（随机种子生成器）的高延迟最反直觉。
追下去发现，每次游戏开始都要向后端要一个新种子，保证随机性不可预测。但作者重新审视需求：这个"不可预测"真的需要服务器参与吗？
答案是否定的。他把种子生成搬到客户端，用时间戳+用户ID的哈希组合，既保证局间随机性，又砍掉一次网络往返。
一个接口直接消失，成本和延迟双降。
回到免费档的代价
三处改动做完，账单曲线掉头。
Firestore读取从日均100万压回免费阈值内，月费归零。HTTP延迟的体感改善没有量化数字，但监控上的毛刺少了。
作者没提具体优化后的读取数字，但"back to Firebase free tier"（回到Firebase免费档）这个结果本身，就是独立开发者最硬的指标。
整个过程他没重写架构，只是用可观测性工具定位AI代码的隐性债务，然后针对性修补。N+1查询、过度请求、伪需求接口——这三类问题在AI生成代码里反复出现，因为AI擅长"让代码跑起来"，不擅长"让代码 scalable（可扩展）"。
给你的检查清单
如果你也在用AI工具搭项目，这张清单可能比优化技巧更重要：
后台任务必须审计。AI写的定时任务、清理函数、数据同步脚本，是小规模测试覆盖不到的盲区。上线后第一件事：看它的读取模式是不是和记录数线性相关。
前端缓存不是可选项。AI生成的客户端代码倾向于"简单直接"，每次要数据就请求。自己加一层本地状态管理，收益往往比后端优化更高。
质疑每一个接口的必要性。random seed这个案例说明，AI会"过度工程化"地实现需求——用服务器解决本可用客户端解决的问题。定期问自己：这个调用能不能省掉？
可观测性要前置。作者如果等账单涨到100美元再排查，修复成本会高一个数量级。Firestore的Query Insights、Cloud Monitoring的HTTP指标，这些免费工具在第一天就该打开。
最后一条：AI代码的"能跑"不等于"能撑"。小规模验证时，N+1查询和重复请求都被数据量掩盖了。用户过500、过5000的时候，这些债务会连本带利追回来。
热门跟贴