clion 不支持直接调试动态库本身，只能调试加载该库的宿主进程；需确保宿主程序正确链接并调用库函数、动态库带调试信息且路径配置正确，再通过启动宿主或附加进程方式进行调试。
CLion 本身不支持直接“调试动态库本身”（比如单独启动一个 .dll 或 .so 文件），它只能调试正在运行的、加载了该库的宿主进程（如可执行程序或 Java 进程）。 想单步进入 customLibTest 函数？必须让这个函数被调用，且宿主进程在 CLion 控制下启动或附加。
调试前必须确保宿主进程加载了你的动态库
常见错误是：编译出 libtestdll.dll，但运行的可执行文件没链接它，或者没把 DLL 放到 PATH / 当前目录 / 可执行目录下，结果断点永远不命中，CLion 显示 “No executable code found”。
- Windows 下检查是否加载成功：在调试时打开 Debug → Views → Loaded Libraries，确认
libtestdll.dll在列表中；若没有，说明加载失败 - Linux/macOS 下用
ldd ./your_executable查看是否能解析到libtestdll.so；运行时报libtestdll.so: cannot open shared object file就是路径问题 - CLion 默认不会自动把生成的
.dll/.so复制到可执行文件所在目录，需手动配置 CMake 的add_custom_command或在Run Configuration → Environment variables中加PATH=xxx;${PATH}（Windows）或LD_LIBRARY_PATH=xxx:${LD_LIBRARY_PATH}（Linux）
给 C++ 宿主程序附加调试器（最常用）
这是 Windows/Linux/macOS 下最稳定的方式：先用 CLion 启动你的可执行程序（它会自动加载你写的 .dll 或 .so），然后在你想调试的函数入口打行断点（比如 customLibTest 第一行）。
- 确保 CMakeLists.txt 中对动态库使用了
add_library(yourlib SHARED ...)，且宿主可执行目标用了target_link_libraries(host_exe yourlib) - 宿主程序源码里必须显式调用库中函数（哪怕只是
customLibTest("1");），否则优化可能把整个函数段丢掉，断点无效 - 如果宿主是控制台程序，CLion 默认用 PTY 启动，I/O 行为接近终端；若依赖 Windows 控制台 API（如
GetStdHandle），建议在Run Configuration → Execution → Use external console打勾 - 调试时若看到变量显示为
<optimized out></optimized>，说明编译用了-O2或更高优化级 —— 务必把 CMake 构建类型切到Debug（工具栏右下角切换），并确认CMAKE_BUILD_TYPE是Debug
远程附加到已运行进程（如 Java + JNI）
当动态库被 Java 调用（通过 System.loadLibrary("testdll")），而你无法/不想从 CLion 启动 JVM 时，用 “Attach to Process” 更实际。
- Java 进程必须用
-agentlib:jdwp=...启动（启用 JDWP），但这对本地 native 调试无用；真正需要的是 JVM 加载了你的 DLL 并正在运行，且你有它的 PID - CLion → Run → Attach to Process → 选中对应进程（如
java.exe或java）→ 点击 OK；此时 CLion 会用 GDB/LLDB 附加，符号若加载正确，你就能在library.cpp里打断点了 - 关键前提：你的动态库编译时带调试信息（
set(CMAKE_CXX_FLAGS_DEBUG "-g")），且 CLion 能定位到源码（即项目根目录包含library.cpp和library.h） - Java 是 64 位？那 DLL 必须是 64 位（MinGW-w64 或 MSVC x64 工具链），否则
UnsatisfiedLinkError或直接崩溃 —— 这个位数匹配问题比路径问题更隐蔽
真正容易被忽略的是：CLion 调试动态库的“上下文”完全依赖宿主进程。没有宿主，就没有调用栈、没有线程、没有内存映射，断点只是摆设。与其纠结怎么“单独调试 DLL”，不如花两分钟确认三件事：DLL 是否真被加载、宿主是否真调用了导出函数、调试符号和源码路径是否一一对应。
