leak避坑：别只盯工具
leak避坑的核心不是“装了扫描器就安全”，而是理解泄漏怎么发生、为什么会漏、漏出去之后还能不能止血。很多事故不是技术太难，而是边界没画清、权限没收住、日志太放飞。
总览：leak本质是边界失守
不管是内存 leak、数据 leak，还是密钥 leak，背后的逻辑都差不多：某个东西本该待在受控范围里，却跑到了不该出现的地方。密钥进了 Git，用户隐私进了日志，内部字段进了前端响应，内存对象被引用链拴住，都是边界失守。
所以 leak避坑不能只问“用什么工具”。更该问三件事：谁能接触它、它会流向哪里、失控后怎么撤回。把这三问搞清楚，工具才有用。
坑一：把“内部环境”当安全区
很多泄漏都死在一句话上：反正只有内部能看。内部日志、测试库、临时对象存储桶、聊天群截图，听起来都不公开，但权限经常比你想象中大。外包、实习、离职账号、共享机器人，都可能成为扩散点。
避坑做法很直接：内部数据也按敏感级别处理。日志默认脱敏，测试库用假数据，临时文件设置过期时间，对象存储桶禁止 public-read。别等到搜索引擎收录了你的备份文件，再说“它本来只是临时放一下”。
坑二：只保护入口，不检查出口
很多团队很重视登录、鉴权、网关，却很少检查接口返回了什么。结果权限没破，数据自己跑出去了。比如订单接口给买家返回了供应商结算价，客服接口给普通员工返回了完整身份证。
真正的 leak避坑要做出口审计。每个接口至少标清三类字段：公开字段、登录可见字段、内部字段。前端用不到的字段不要返回，别用“以后可能用”当借口。JSON少一个敏感字段，比加十层网关都实在。
坑三：密钥轮换没有演练
发现密钥 leak 后，很多人第一反应是删提交。问题是删提交不能让密钥失效，真正该做的是轮换。更坑的是，很多系统根本没演练过轮换，一换就全站报错。
建议把密钥分成可热更新和需重启两类。云厂商 AK、数据库密码、第三方 API token，都要记录负责人和轮换步骤。每季度挑一个低风险密钥演练一次，别等事故当天才发现没人知道这个 key 配在哪。
收口：把leak当流程问题修
leak很少是单点问题。一个密钥能泄出去，通常说明提交前没扫、合并时没拦、泄漏后没告警、轮换流程不熟。一个字段能漏出去，也常常是接口设计、评审、测试都没管字段级权限。
最省钱的修法不是买更贵的平台，而是把高频坑写进流程：提交前扫密钥，日志默认脱敏，接口返回做字段评审，密钥定期轮换。每个动作都不炫，但能少很多深夜救火。
推荐阅读
常见问题
leak避坑最重要的一条是什么？
不要相信“内部就安全”。内部日志、测试库、临时文件都要按敏感数据处理，尤其要控制访问和保留时间。
发现密钥泄漏后先删代码可以吗？
删代码不是第一步。先吊销或轮换密钥，再清理历史提交，最后排查这段时间有没有异常调用。
接口字段泄漏怎么预防？
给字段分级，默认只返回业务必需字段；新增接口评审时检查响应 JSON，不要把数据库对象原样丢给前端。