程序运行无报错但结果错误时，需定位逻辑断点；应按执行流程在每函数返回后打印日志或设断点检查变量值，如std::cout。
程序能跑通、没崩溃、但结果不对——这种问题最耗时间，因为编译器不报错、调试器不中断，你得自己揪出逻辑断点在哪里。
先定位出错阶段：别从 main 一行行看
假设流程是 read_input() → parse_json() → filter_data() → compute_result() → print_result()，错误可能卡在任意一环。盲目扫代码效率极低。
实操建议：
- 在每个函数返回后立刻打日志或用断点检查关键变量值，例如：
std::cout - 如果
parse_json()返回的data已经少了一半字段，那问题就在它内部，不用往下查 - 对中间数据做简单断言，比如
assert(!data.empty());，提前暴露异常输入 - 避免“我以为它对了”——哪怕
parse_json()看似成功，也要验证字段值是否符合预期（比如字符串是否被截断、数字是否解析成 0）
重点盯紧浮点数、整数除法和隐式类型转换
这类错误不会 crash，但会让结果系统性偏移，比如预期 100 却得到 98 或 0。
立即学习“C++免费学习笔记（深入）”；
常见坑：
-
int a = 5, b = 2; double r = a / b;→r是2.0而不是2.5，因为整数除法先截断 - 把
double存进float变量，精度丢失后参与后续计算，误差滚雪球 - 函数参数是
int，你传了size_t（尤其在 Windows 下是 unsigned long），负数被转成极大正数 - JSON 解析库把
"123"解成int没问题，但把"123.45"解成int就直接截断成123
边界条件和空输入最容易被忽略
多数测试用例覆盖的是“正常路径”，而结果偏差往往来自边缘 case。
必须手动验证：
- 输入为空容器、空字符串、null JSON 对象时，
filter_data()是否返回空？还是意外跳过判断逻辑？ - 数组下标用
i-1计算时，i == 0会导致size_t下溢成极大值，越界访问 - 循环结束条件写成
i 而不是 <code>i ，多跑一次 - 时间戳、ID 等字段为 0 或负数时，是否被当成非法值过滤掉？
并发场景下结果随机波动
如果程序开了多线程，结果每次运行都不一样，大概率是数据竞争，而不是算法错。
快速确认方法：
- 加
-fsanitize=thread重新编译运行，TSan 会直接指出哪两个线程在无锁情况下读写同一变量 - 临时改成单线程（注释掉
std::thread相关代码），如果结果稳定了，问题就出在并发逻辑 - 检查所有共享变量：是否都用了
std::atomic或加锁？std::vector的push_back()不是线程安全的 - 注意
std::shared_ptr的引用计数是原子的，但指向的对象内容不是——别误以为用了智能指针就自动线程安全
最常被绕开的其实是输入本身：文件编码不对、换行符是 \r\n 不是 \n、JSON 多了个逗号但解析器静默跳过……结果不对，有时根本不是代码的问题，而是你根本没拿到想要的数据。
