编译错误时，g++或clang++报错信息中的文件名:行号:列号（如main.cpp:23:15）即为精准位置，IDE中点击可跳转，终端可用vim +23 main.cpp打开；模板错误需优先查看最上方几行，链接错误若含行号则依赖目标文件带-g编译，运行崩溃须用gdb配合-g和bt定位。
编译错误时怎么看清 g++ 或 clang++ 的报错位置
编译器报错信息里其实已经包含了源文件路径和行号，但默认可能被截断、折叠，或混在大量模板展开中看不清。关键不是“找不到”，而是“没注意过滤干扰信息”。
典型错误行长这样：
main.cpp:23:15: error: no matching function for call to 'foo'
这里的
main.cpp:23:15 就是文件名、行号、列号——直接跳转即可。
- 用 VS Code / CLion 等 IDE 时，点击该行（或按 Ctrl+Click）会自动打开
main.cpp并定位到第 23 行 - 终端里用
vim +23 main.cpp或code +23 main.cpp快速打开 - 如果路径是相对路径（如
./src/util.h），确保你在正确的构建目录下运行编译命令，否则编辑器可能打不开 - 模板错误常伴随几十行“note: candidate template ignored”，真正出问题的那行通常在最上面几行，别往下翻太久
运行时崩溃（Segmentation fault）怎么定位源码行
崩溃本身不带行号，必须靠调试器或符号信息才能回溯。没加 -g 编译就基本只能靠猜。
- 编译时务必加上
-g：例如g++ -g -o app main.cpp，否则gdb进去看不到变量、也显示不了源码行 - 用
gdb ./app启动后运行run，崩溃后立刻输入bt（backtrace），第一帧通常就是出问题的源文件和行号，如#0 0x00005555555561a2 in process_data (input=...) at parser.cpp:47 - 如果程序是被信号中断（比如
kill -SEGV），可提前用ulimit -c unlimited开启 core dump，再用gdb ./app core加载分析 - Clang 用户可尝试
clang++ -g -fsanitize=address，ASan 会在崩溃时直接打印带行号的内存错误详情
链接错误（undefined reference to）为什么看不出具体哪行调用的
链接器（ld）只管符号，不管调用位置；它报的错误是“找不到函数定义”，但不会告诉你哪个 .cpp 文件里的哪行代码触发了这个调用。
立即学习“C++免费学习笔记（深入）”；
- 错误形如：
main.o: in function 'main': main.cpp:12: undefined reference to 'helper_func()'—— 这里的main.cpp:12是调用点，但前提是目标文件（main.o）是用-g编译的 - 如果没加
-g，链接错误里通常只有.o文件名，没有行号；此时要反查：在main.cpp中搜helper_func()，再确认是否漏了实现或忘记加对应源文件进编译命令 - 常见坑：声明在头文件、定义在
.cpp里，但编译时没把那个.cpp加进去；或者用了inline却没在头文件里定义
日志或异常抛出时想自动打出当前行号，怎么写宏
C++ 没有内置行号日志，但可以用预处理器宏 __FILE__ 和 __LINE__ 拼接，避免手写硬编码。
- 简单安全的写法：
#define LOG_ERR(fmt, ...) fprintf(stderr, "[%s:%d] " fmt "\n", __FILE__, __LINE__, ##__VA_ARGS__)
调用LOG_ERR("failed to open %s", path);会输出类似[config.cpp:89] failed to open /etc/app.conf - 注意
__FILE__默认是绝对路径，太长可改用strrchr(__FILE__, '/')截取文件名，但需自己处理空指针 - 如果用
std::cerr，别直接拼接字符串流（容易因类型推导失败编译不过），建议封装成函数对象或用fmt库替代 - 宏在内联函数或模板中展开时，显示的是宏定义处的行号，不是调用处——这点容易误判，真要精确得用
std::source_location（C++20）
最常被忽略的一点：所有这些行号能力都依赖编译器能“看到源码”。如果用 CMake 构建，确认 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g") 真的生效了，而不是只加在某个 target 上漏掉了主程序。
