本地测试全绿，上线当天被刷爆。这是AuthShield项目第四阶段的教训——作者以为最难的是写代码，结果发现生产环境专治各种不服。
前情提要：这是一个独立认证微服务，从0到1经历了OAuth陷阱、JWT状态层重构，现在到了真正的地狱模式。四个看似简单的环节——限流、测试、邮件、Docker——每个都藏着让安全假设当场失效的细节。
限流不是配置项，是数学题
固定窗口限流有个致命边界：攻击者在59秒发送5次请求，下一秒再发5次，两秒内完成10次暴力破解，而你的系统以为只过了1分钟。
Redis有序集合实现的滑动窗口方案，用时间戳当分数，自动淘汰过期记录。没有重置点，没有可预测的漏洞窗口。代码里那行zremrangebyscore不是优化，是安全底线。
作者原话：「我假设限流是个配置问题，结果发现是算法选择问题。」
集成测试的幻觉
单元测试覆盖90%代码，上线后数据库连接池耗尽。本地用SQLite跑测试，生产是PostgreSQL；本地单线程，生产并发200。测试通过了，但测试的是错误的东西。
AuthShield的解决方案：Docker Compose拉起完整依赖栈，Redis、Postgres、SMTP mock全量模拟。测试执行时间从30秒涨到4分钟，但第一次在生产环境之外发现了连接泄漏。
作者算过账：4分钟测试 vs 凌晨3点被叫醒修故障，这个ROI不需要讨论。
邮件系统的身份危机
开发阶段用Mailtrap，所有邮件进了黑洞，完美。切到生产SMTP，DKIM签名失败、SPF记录冲突、Gmail直接扔进垃圾箱。用户收不到验证码，以为是系统bug，其实是邮件信誉度为0的新域名。
更隐蔽的问题：SMTP连接池和HTTP连接池混用，异步任务里同步发送邮件，超时设置30秒——一个慢响应的邮件服务商能拖垮整个登录接口。
最终方案：专用邮件队列服务，独立连接池，5秒超时，失败进死信队列人工介入。认证系统的可用性不能依赖第三方邮件的稳定性。
Docker多阶段构建的隐藏成本
第一阶段用Python 3.11-slim装依赖，第二阶段复制产物。镜像从1.2GB压到180MB，启动时间从8秒降到2秒。数字好看，但生产环境发现新Python版本有个SSL兼容性问题，只在特定Alpine基础镜像上出现。
回滚方案花了两天：不是代码回滚，是基础镜像版本锁定、依赖冻结、构建缓存清理。作者笔记里写：「多阶段构建省的是磁盘，赌的是运气。」
四个问题，没有一个是代码层面的复杂算法。限流是时间窗口的数学定义，测试是环境 fidelity 的取舍，邮件是外部依赖的隔离策略，Docker是基础镜像的供应链管理。
AuthShield现在跑在生产环境，作者最后更新了一行文档：「下次先部署空服务，验证基础设施，再写业务代码。」——这顺序反了四年，现在改还来得及吗？
热门跟贴