Ctrl+C 发送的是 SIGINT 信号，脚本默认立即终止导致资源残留；用 trap 捕获 SIGINT 并执行 cleanup 函数可实现优雅退出，但需注意变量展开、显式 exit、子进程清理及 SIGKILL 不可捕获等限制。
Ctrl+C 不是“强行终止”的错误操作，而是标准的 SIGINT 信号发送行为；真正的问题在于脚本没做响应，导致临时文件、子进程、锁等残留。用 trap 捕获它，就能实现优雅退出。
为什么 Ctrl+C 后脚本直接退出还留一堆垃圾？
默认情况下，Bash 脚本收到 SIGINT（编号 2）会立即终止，不执行任何后续代码。你写的 rm -f /tmp/xxx 或 kill $pid 如果放在主流程末尾，根本来不及运行。更隐蔽的是：子进程可能还在跑，变成孤儿进程；touch /var/lock/myapp.lock 这种锁文件也不会自动删除。
-
Ctrl+C触发的是SIGINT，不是崩溃，也不是语法错误 - 退出码通常是
130（= 128 + 2），看到这个数基本可确认是被中断的 -
trap是唯一能让你在信号到达瞬间插入清理逻辑的机制
trap SIGINT 的正确写法和常见错误
最简可用写法是把清理命令直接写进 trap，但要注意 shell 解析顺序和变量作用域。下面这些写法容易出问题：
- 错误：用双引号包裹整个命令，且里面含未转义的变量——
trap "rm -f $TMPDIR/*; exit 1" INT，$TMPDIR在定义 trap 时就被展开，不是触发时 - 正确：用单引号避免提前展开，或改用函数封装——
trap 'cleanup; exit 1' INT - 别漏掉
exit：trap 处理完后脚本默认继续执行，必须显式退出，否则后续逻辑可能误跑 - 多个信号可一起捕获：
trap 'cleanup; exit 1' INT TERM，这样kill 1234也能触发清理
实际脚本中怎么组织 cleanup 函数？
把清理逻辑抽成函数，比一行命令更可控、易测试、可复用。关键点是：函数内要能访问到主流程创建的资源句柄（如 PID、临时路径），且不能依赖外部环境变量未初始化的状态。
- 推荐在脚本开头就定义好关键变量，比如
WORK_DIR=$(mktemp -d)，然后在cleanup()里直接引用 - 子进程要显式
kill并wait，否则trap执行完父进程退出，子进程可能继续跑：kill $CHILD_PID 2>/dev/null; wait $CHILD_PID 2>/dev/null - 加日志输出方便调试：
echo "[$(date +%T)] cleanup triggered by SIGINT" >&2 - 示例片段：
cleanup() { echo "Cleaning up..." rm -rf "$WORK_DIR" [ -n "$SERVER_PID" ] && kill "$SERVER_PID" 2>/dev/null exit 1 } trap cleanup INT TERM
SIGINT 无法覆盖的边界情况
trap 对 SIGINT 有效，但不是万能的。有些场景它完全不起作用，得提前规避：
-
kill -9 $PID发送的是SIGKILL（编号 9），不可捕获、不可忽略——这是设计使然，不要试图 trap 它 - 脚本正在执行阻塞系统调用（如
read等待输入、sleep未到期）时，SIGINT可能延迟送达，但最终仍会触发 trap - 如果脚本里用了
exec替换当前进程（如exec python3 server.py），后续信号由新进程接管，原 trap 失效 - 子 shell（括号内命令）里的 trap 不会继承到父 shell，
(trap 'echo hi' INT; sleep 10)按 Ctrl+C 只影响子 shell
真正难处理的从来不是 Ctrl+C 本身，而是清理动作是否覆盖所有资源类型——特别是子进程生命周期、文件锁、网络连接状态这些隐性依赖。trap 只是入口，清理逻辑是否完备，决定了脚本在生产环境里能扛住几次意外中断。
