给合作方开一个沙箱：目录站的对接环境该怎么交付

目录站做到一定规模，总会遇到对接需求：有人要拉你的分类数据，有人要给你的条目表同步信息，有人要做联合的检索。第一次对接时最常见的做法是发一对生产密钥过去，说"你先调着，小心点"。

这个做法的问题不是对方不可信，而是你没有退路：密钥一旦发出去，出问题只能整对换掉，而且你不知道对方拿它做了什么。

图片来源：网络，版权归原作者所有，侵权请联系删除

沙箱要有四样独立的东西

资源	生产	沙箱
域名	主域	独立子域，加 noindex 和基础认证
数据	真实数据	脱敏快照或构造数据
凭据	长期密钥	独立密钥，设有效期
配额	按合同	更严的限流，方便对方触发错误分支

子域要单独加防护。沙箱被搜索引擎抓到是挺常见的坑，一堆测试数据进了索引，后面清理很烦。除了 robots 里禁止，直接加一层基础认证最省事，反正对方是开发者。

数据从哪来

两条路：脱敏的生产快照，或者构造数据。我偏向前者加随机扰动，因为真实数据的分布特征（字段缺失、异常长度、奇怪的分类）恰恰是对方最容易踩坑的地方，构造数据往往太规整，联调通过了上生产还是报错。

脱敏不是把手机号打星号就完事。关联字段要一起改：站名脱敏了但域名留着，等于没脱；ID 打乱了但创建时间和条目名的对应关系还在，照样能反推。脱敏规则要覆盖整条链路，做完之后自己试着还原一次，能还原出来就说明没做干净。

量不用大。沙箱有一万条条目就够联调分页、排序、过滤了，全量快照既慢又增加泄露面。

别让它变成第二个生产

沙箱最典型的衰变是数据老化：上线半年后，里面的数据还是半年前的，接口行为已经和生产的对不上了，联调通过上生产还是出错。

我的做法是定期重置，重置周期写进文档并提前通知对方。同时把沙箱的接口版本跟生产对齐，生产灰度变更时沙箱同步更新。做不到自动同步，至少每次发版时人工确认一次。

另一个常见问题是配额设得太宽松，对方拿沙箱跑压力测试，把你的环境压垮了。沙箱的限流应该比生产更严，而且要让对方能真的触发到 429，错误分支也是联调的一部分，不少对接事故就出在对方没处理限流响应上。

验收清单

交付时给对方一份清单，比口头说清楚有用：联调用例覆盖哪些场景；错误码和限流响应分别长什么样；数据多久重置一次；出了问题找谁，响应多久。最后一条尤其重要，沙箱挂了对方干等三天，合作关系比事故本身更伤。

沙箱做得好不好，看一个指标就够了：对方上生产时是不是一次通过。做不到一次通过，多半是沙箱的数据或配置和生产的差异太大，等于白搭。