--error-limit=no 是为禁用错误数量限制，确保 valgrind 报告所有内存错误；默认 --error-limit=yes 会在约 1000 错误后截断，易遗漏关键问题，而 no 参数可避免此问题，但需配合 -g、--leak-check=full 等使用才能完整呈现。
关掉 --error-limit=no 是为了不丢弃后续错误
默认情况下，Valgrind 在报告约 1000 个错误后会停止记录新错误，并输出类似 Too many errors, stopping at 1000 的提示。这会导致你漏掉后面真正关键的内存问题——比如程序末尾才发生的泄漏或越界写，根本没机会被看到。
加 --error-limit=no 就是告诉 Valgrind：别停，全给我记下来。尤其在复杂程序、长生命周期服务或带大量测试用例的场景下，这个开关几乎是必开的。
--error-limit=yes 和 --error-limit=no 的实际差异
它不是“开/关”布尔值意义上的开关，而是一个明确的字符串参数：
-
--error-limit=yes（默认）：达到内部阈值（通常是 1000）后静默截断，不再报告新错误 -
--error-limit=no：禁用截断，所有检测到的错误都会输出（可能极大拉长日志）
注意：--error-limit 不接受 true/false 或 1/0，只认 yes 和 no；输错会报错并退出。
容易踩的坑：开了 --error-limit=no 却看不到全部错误
常见原因有这几个：
- 没加
--leak-check=full：即使错误没被截断，泄漏本身也不会被详细列出，只会显示 summary - 程序提前崩溃或被 kill：Valgrind 只能在进程正常退出后才汇总泄漏；如果 crash 了，
memcheck可能根本来不及报告 - 日志被重定向但没加
--log-file或--log-fd：大量错误刷屏后滚动丢失，建议固定用--log-file=report.log - 忘了编译时加
-g：错误堆栈显示为???，看着像“没报全”，其实是符号缺失
性能与实用性之间的权衡
--error-limit=no 本身几乎不增加运行开销，但它会让日志体积暴涨——尤其是存在大量未初始化内存读取（Use of uninitialised value）时，一条循环可能产生成百条重复错误。
这时更实用的做法是：
- 先用
--error-limit=no跑一次，确认错误总量和类型分布 - 再配合
--suppressions=mysupp.supp屏蔽已知误报 - 或用
--max-stackframe=8M防止因超大栈帧导致崩溃而中断检测
真正难处理的从来不是“报太多”，而是“报了但看不懂”或者“该报的没报出来”——--error-limit=no 只解决前者的一小部分，别指望它自动治好内存 bug。
