脚本日志需结构清晰、字段一致：统一头部模板[时间][任务名][主机名][pid]，分级输出info/warn/error至不同通道，关键节点（启动/结束/跳过/重试）必留痕迹，配合大小与天数限制的日志轮转。
脚本执行日志要让人一眼看懂“谁、什么时候、干了什么、结果如何”，关键不是堆信息，而是结构清晰、字段一致、便于排查。
固定日志头部模板
每条日志开头统一用固定格式标记上下文，避免手写时间或随意拼接。推荐使用：
[$(date +'%Y-%m-%d %H:%M:%S')][任务名][主机名][PID]
- 时间用
date +'%Y-%m-%d %H:%M:%S'，不带毫秒但可读性强，也方便按行切分 - 任务名建议从脚本名或配置中提取（如
backup_mysql），别写“定时脚本”这类泛称 - 主机名用
hostname -s，多机部署时快速定位来源 - PID用于区分并发实例，尤其在循环调用或并行任务中很实用
区分日志级别与输出通道
INFO、WARN、ERROR 不只是加个前缀，要对应不同输出行为：
- 正常流程用
echo "[INFO] 备份完成：/data/backup/20240520.sql"→ 输出到 stdout（重定向进日志文件） - 警告类（如磁盘剩余echo "[WARN] 空间不足，跳过压缩" >&2 → 输出到 stderr，便于单独过滤
- 错误必须含退出码和上下文，例如：
echo "[ERROR][exit=1] mysqldump 执行失败，返回码: $?" >&2
关键动作必留痕迹
启动、结束、跳过、重试这四类节点不能省略，哪怕只是单行记录：
- 脚本开头记一句
[INFO] 开始执行 backup_mysql（版本 v2.1） - 主逻辑前后加耗时统计：
[INFO] 执行耗时：27.3s - 条件判断导致跳过时明确说明原因：
[INFO] 跳过：无新增数据（last_update=2024-05-20） - 重试机制需编号和间隔：
[WARN][retry=2/3] 连接超时，30s后重试
日志归档与轮转控制
不控制体积的日志等于没日志。建议在脚本末尾或独立清理逻辑中处理：
- 单个日志文件不超过 10MB，超限自动切割（可用
logrotate或脚本内用tail -n 10000截断） - 保留最近 7 天日志，旧文件压缩为
app.log.20240515.gz格式 - 避免用
>>无限追加，改用exec >> "$LOGFILE" 2>&1统一接管输出，再配合轮转逻辑
规范不在多，而在每处都执行到位。字段对齐、通道分离、节点完整，查问题时就能少翻十页日志。
