kill -l 按序号列出所有信号名称（无sig前缀），括号内为序号而非编号；查编号用 kill -l signame；脚本中应使用符号名如 kill -s term pid 而非数字，以确保跨平台兼容性。
kill -l 能列出所有信号，但输出格式容易误读
执行 kill -l 是最直接的方式，它会按编号顺序输出全部信号名称（不含 SIG 前缀），比如显示 1) SIGHUP，而不是 SIGHUP=1。注意：括号里的数字是序号，不是信号编号——第一行的 1) 对应信号编号 1，第二行 2) 对应编号 2，以此类推。
常见误操作是把序号当编号用，比如看到 10) SIGUSR1 就以为信号编号是 10，其实没错；但看到 32) RTMIN 就可能困惑——因为编号 32 在多数系统上并不存在（kill -l | wc -l 通常返回 64 行，但实际有效编号是 1–31 和 34–64，32/33 空缺）。
- 查某信号编号：用
kill -l SIGTERM或kill -l term（大小写不敏感，SIG可省略） - 过滤实时信号：用
kill -l | grep RT，RTMIN起始编号因内核而异，常见为 34 - 脚本中安全取值：避免解析带括号的输出，改用
kill -l TERM直接得数字 15
man 7 signal 比 kill -l 更关键，它告诉你信号能不能捕获
kill -l 只给名字和编号，man 7 signal 才解释行为：哪些信号不能忽略（如 SIGKILL、SIGSTOP），哪些默认产生 core dump（如 SIGQUIT、SIGSEGV），哪些常被服务用来重载配置（如 SIGHUP）。
例如查 SIGUSR1：手册里明确写 “Default action: Term”，但几乎所有服务都把它留给自定义用途——Nginx 用它做平滑升级，Redis 用它生成 RDB 快照。没查手册就发，可能触发意料外行为。
- 重点关注 “Default action” 和 “Signal description” 两栏
- 搜索时用
/^SIGHUP（正则开头匹配），避免命中其他段落 - 某些精简容器镜像里
man不可用，此时需依赖kill -l+ 已知惯例，或进容器查/usr/include/asm-generic/signal.h
发送信号前必须确认进程状态，否则可能白发或误杀
用 kill -0 PID 是唯一不扰动进程的校验方式：它只检查进程是否存在、当前用户是否有权限发信号，不真发。返回 0 表示可操作，非 0（通常是 1）表示进程已退出或权限不足。
直接 kill -15 PID 再观察，比盲目 -9 安全得多。尤其对数据库类进程（PostgreSQL、MySQL），SIGTERM 触发的是优雅关闭流程；SIGKILL 可能导致 WAL 未刷盘、表损坏。
- 先
kill -0 1234，再kill -TERM 1234，等 3 秒后ps -p 1234确认是否退出 - 对 systemd 服务，优先用
systemctl reload service_name（它内部可能转成SIGHUP，但做了更多前置检查） - 批量操作前，用
pgrep -f "python app.py" | xargs -r kill -0预检，-r防止无输出时xargs报错
别依赖信号编号写脚本，用符号名更可靠
不同系统信号编号可能微调（尤其嵌入式或旧内核），但符号名稳定。kill -s TERM 1234 和 kill -15 1234 效果一样，但前者可读、可维护、跨平台兼容性更好。
在 shell 脚本里硬写数字，过两年换环境发现 SIGRTMIN 偏移变了，或者某发行版把 SIGPOLL 编号从 29 改成 30，脚本就失效。而 kill -s HUP 始终指向挂起信号。
- 脚本中统一用
kill -s SIGNAL_NAME PID格式 - 需要动态拼接时，用变量存名称：
sig=HUP; kill -s "$sig" "$pid" - CI/CD 流水线里若禁用
man或头文件，kill -l SIGNAL_NAME仍可作为运行时校验手段
man 7 signal 和目标进程文档交叉验证。
