处理子进程的信号退出不正确

This is not quite correct, as the Rust docs allude to when they say, "An `ExitStatus` represents every possible disposition of a process. On Unix this is the wait status. It is _not_ simply an exit status (a value passed to `exit`)." The 128 + n behavior is the behavior of the _shell_: if a process exits with a signal, the shell will set `$?` to 128 + n. But the shell will _also_ print a message indicating the signal, e.g. "Segmentation fault (core dumped)" or "Killed". It can do this because at the OS/kernel level, the UNIX wait status is a two-byte field. There are eight bits (not seven!) for the argument to `exit` (or, equivalently, the return value of `main`), seven bits for the signal, and one bit for whether core was dumped. If the signal field is zero, then the process exited normally and the exit status field is meaningful; otherwise the signal field is meaningful. (There are a few more variants of interpreting the 16-bit exit status field if a process is stopped without exiting or continued from being stopped; they aren't particularly relevant here, I think.) In practice, this produces the bug that `uv run Python` etc. differs from directly running `Python` if the process terminates with a signal, because to the shell, `uv` appears to _exit normally with an exit code over 128_ as opposed to exiting with a signal: