科技 · 实用指南
命令手动能跑，crontab 却失败？改脚本前先还原 cron 上下文
先证明 cron 确实启动了该行，再对比真实用户、shell、环境、工作目录和输出路径，并验收一次真正的定时运行。
命令在交互终端成功，不代表它在 cron 下拥有相同的进程上下文。实际用户、shell、PATH、HOME、工作目录、密钥来源与输出处理都可能不同。
不要先扩大权限或加载整个登录配置。先证明是否启动，捕获一次运行，用最小环境重现，再只补上缺失依赖。
1. 证明 cron 尝试过执行
编辑前先读取已安装的 crontab、cron/crond 服务状态，以及计划分钟对应的系统日志。没有调度事件、已启动 shell、程序返回非零，是三种不同故障。
对一次受控运行，把 stdout 和 stderr 重定向到受保护的绝对路径，并追加数字退出码与时间戳。若实现会邮寄输出，应单独验证投递，不能把安静当成功。
2. 确认准确的 crontab 与用户
记录该行来自用户 crontab、root crontab、/etc/crontab 还是 /etc/cron.d。系统表包含显式用户字段，在格式之间复制同一行会改变解析。
以实际调度账户记录 id、组、HOME、SHELL 和完整 crontab。不要假定编辑文件的管理员就是执行身份。
3. 建立上下文差异表
只比较任务确实需要且已审查的变量：PATH、区域、代理、应用配置与凭据文件位置。当前 crontab 手册说明 cron 设置 SHELL、HOME、LOGNAME，而部分值可在 crontab 中覆盖。
不要把完整环境写进公开日志，其中可能含令牌。只记录变量名和脱敏后的存在状态，再用绝对解释器与程序路径证明每次查找。
4. 明确路径和工作目录
Cron 不保证从脚本目录启动。使用显式 cd -- /绝对/项目 && 命令，或把输入、输出、锁与临时路径全部写成绝对路径。
以调度用户检查目录遍历权限，并确认文件存在于同一命名空间。root 终端测试不能证明普通用户 cron 能访问相同路径。
5. 不等下一分钟也能重现
使用 env -i，只带预期的 HOME、PATH、SHELL 和已审查应用变量，以调度用户执行一次测试。这能快速还原边界，无需等下一次时钟。
使用与 crontab 相同的解释器和工作目录。最小测试失败时，问题属于上下文或程序假设；成功时再回到计划、daemon 或策略证据。
6. 只修一项依赖并验收
只添加缺失的路径、变量、目录切换、凭据文件或服务依赖。除非理解全部副作用，不要加载完整交互配置；也不要把秘密放进可公开读取的 crontab 或调试日志。
安排一次短测试，要求开始标记、结束标记、退出码以及预期产物或下游状态全部出现。随后恢复正式频率、移除临时日志并保留脱敏台账。
