必须在主进程fork关键子进程且需分析其内存行为时启用--trace-children=yes，如daemon派生worker、system()/popen()调用外部工具或ci中启动临时服务；单进程程序无需开启。
什么时候必须用 --trace-children=yes
--trace-children=yes 只在主进程会 fork 出关键子进程、且你关心子进程内存行为时才需要开启。典型场景包括：
- 后台服务（daemon）启动后主动 fork 子进程处理请求，比如早期版本的
nginx、lighttpd或自研 C/S 架构中由父进程派生 worker 进程 - 测试程序中调用
system()、popen()或fork()+exec执行外部工具，并怀疑子进程存在泄漏或越界 - CI 环境中运行集成测试套件，其中某个测试 case 会拉起临时子服务（如嵌入式 SQLite server、mock HTTP server）
它不是通用开关——如果你的程序是单进程、静态链接、不调用 exec 类函数，加这个参数毫无意义，还可能拖慢检测速度。
--trace-children=yes 的实际限制和坑
Valgrind 对子进程的跟踪能力有限，不是“自动递归监控所有后代”。真实表现包括：
- 子进程必须是同一用户权限下可执行的二进制（无法跟踪 setuid 程序或容器内进程）
- 若子进程自身又 fork 出孙进程，
--trace-children=yes默认不继续向下穿透；需配合--trace-children-skip=或重复启用（但支持不稳定） - 某些发行版的 glibc 动态链接器（如较新
ld-linux-x86-64.so.2）在子进程中可能绕过 Valgrind 插桩，导致内存操作静默漏检 - 日志输出会混杂父子进程的报告，
==pid==前缀不同，但堆栈回溯容易断裂，尤其当子进程快速退出时
常见误判：看到 definitely lost 在子进程 pid 下，就认为是子进程代码问题——其实可能是父进程传给子进程的指针本身已失效，或共享内存区域未正确同步。
替代方案比硬开 --trace-children 更可靠
与其依赖这个不稳定选项，不如让问题暴露得更直接：
- 把 daemon 改为前台模式运行（例如
nginx -g "daemon off;"），彻底避免 fork，Valgrind 能全程覆盖 - 对子进程单独做 Valgrind 检测：
valgrind --leak-check=full ./worker_binary arg1 arg2，结果更干净、定位更准 - 若子进程是标准工具（如
grep、curl），优先确认其本身无内存问题，而非把它纳入你的泄漏归因链 - 使用
LD_PRELOAD+ 自定义 malloc hook 配合日志，比 Valgrind 更轻量地观察特定子进程的分配行为
--trace-children=yes 是个应急开关，不是调试主线。真正难查的泄漏，往往藏在父子进程边界处的资源移交逻辑里，而不是子进程内部。
