deploy-landed 用于解决部署命令退出码为 0、但线上仍是旧代码或配置缺失的问题。资料列举的真实陷阱包括：git pull 失败仍继续构建并报告成功；nohup 启动的进程立即死亡却两次返回 0；docker exec 不继承 entrypoint 环境变量导致误判配置缺失；对 bind mount 文件 sed -i/docker cp 会替换 inode，容器仍读旧文件；只在服务器上打的补丁下次部署丢失；wrangler/Pages 中 functions/ 未部署、_headers 被忽略；生产环境处于 SSO 后时，任意路径都返回 401/302，无法证明路由存在；/health 绿灯持续六小时但引擎没有交易。
用法上，拉取或构建前先检查主机是否与 git 一致： git -C /srv/app status --porcelain git -C /srv/app log -1 --format=%H 主机上任何未提交内容，要么先提交，要么报告为 drift，绝不静默覆盖或作为修复的唯一副本。
部署后做四项检查并各附证据。 修订版本：实际服务内容等于目标提交。Cloud Run/k8s 查看在线 revision 的镜像 tag 或 digest，再执行 git merge-base --is-ancestor <commit> <image-tag-sha>；Pages/Workers/Vercel 查看 deployment id 及其 commit；普通主机检查进程启动时间晚于部署、且所服务文件包含新内容（grep 变更引入的字符串）；应用若有 /version 端点则优先。 配置：新代码读取的变量和密钥已存在于运行进程中，按代码期望列表计数。容器内应从 PID 1 读取（cat /proc/1/environ | tr '\0' '\n'），不要用 docker exec env；使用 --set-secrets/--set-env-vars 后要确认未点名的变量仍在，因为这些参数会替换整个集合。 功能：发起一次真正完成产品工作的请求，返回可与已知值比较的结果，例如创建订单、写入一行、在纸上完成一次交易；健康端点只证明进程在运行。 启动错误：查看新 revision 自启动以来的 WARNING 及以上日志；只有确认日志确实在流动时，零行才是有意义的发现。
部署报告末尾应给出如下区块；无法运行的检查必须写 NOT CHECKED 并说明原因，绝不能省略或写成 PASS： DEPLOY-LANDED <service> @ <commit> revision : PASS — serving <revision/deployment id> built from <sha> config : PASS — 14/14 expected vars present in PID 1 function : PASS — POST /orders → 201, row id 8812 visible in DB startup : PASS — 0 WARNING+ lines since 12:04:10 任一行 FAIL 即表示部署未完成，无论命令输出了什么。限制在于：资料未提供自动安装、平台绑定或收费信息，部分命令需按具体环境调整，暂未提供。