上周一朋友他们组提测，开发在群里喊代码合到SIT了，测试一脸懵问SIT是哪个地址，运维甩了个sit链接出来，结果前端连的还是dev接口，调了半天数据对不上。
SIT卡在DEV和UAT之间，专门干联调
一般公司四套环境，DEV是开发自己玩的，天天重启都没人管。SIT是第一个长得像生产的地方，代码冻结后专门给内部联调和冒烟测试用。UAT是给产品和客户验收的，数据更接近真实，PROD就是线上，出事要背锅的。
SIT的地址一般带sit前缀，比如sit-api点自己公司域名，后端分支多半是release分支，Jenkins上有个固定任务一键部署。跟DEV最大区别是，SIT的第三方回调、支付沙箱、短信网关都是配通的，DEV上很多是假数据糊弄的。
提测到SIT之前，先把三件事对齐
- 分支版本：确认提测单上写的提交号和SIT实际部署的一致，别测了个寂寞
- 基础数据：SIT库定期从线上脱敏同步，测试账号找负责人要，别拿DEV的账号硬登
- 开关配置：配置中心的sit命名空间里，定时任务一般是关的，想验证要手动开一次
SIT上最常见的三个坑
一是白名单没加，APP端登录直接报403，后台一看sit域名不在白名单里。二是数据被别的组污染，SIT是共用的，有人压测造了几十万条垃圾数据，列表翻半天。三是缓存没清，后端改了返回格式，前端还读着旧的，一直报错。
排查别靠猜，先看部署时间和日志，用tail看应用日志，或者直接问运维要最近一次构建记录，十分钟就能定位一大半问题。
提测检查：分支已合，版本v2.3.1-sit，测试账号test01，密码看群公告取舍很实在：小团队可以把SIT和UAT合并，省机器省事，业务一复杂，联调和验收天天打架，还是分开省心。