-fvisibility=hidden对静态库无效，因其仅作用于动态库的符号导出，而静态库靠链接时按需提取和头文件设计实现隐藏；真正起效的是static关键字与头文件分层控制。

静态库本身不导出符号，所以“隐藏内部实现”不是靠编译选项控制的，而是靠链接时的按需提取机制和头文件设计决定的。 你无法用 -fvisibility=hidden 或 __attribute__((visibility("hidden"))) 影响静态库的符号可见性——这些只对动态库（.so / .dylib）生效。

为什么 -fvisibility=hidden 对静态库无效

静态库（.a）只是多个 .o 文件的归档，不经过动态链接器，也没有运行时符号表。链接器（ld）在处理 .a 时，只提取其中**被引用到的目标文件**，未被调用的函数/变量根本不会进入最终可执行文件。这意味着：即使你在 internal_function.c 里定义了一个全局函数，只要主程序没调用它，它就不会出现在最终二进制里。

所以，-fvisibility=hidden 这类控制“动态符号导出”的开关，在静态归档阶段毫无作用——它压根不参与符号导出流程。

真正起作用的是头文件 + 链接顺序 + 符号引用关系

静态库的“隐藏”效果，完全依赖于你是否让外部代码能声明并调用某个符号。关键点如下：

GCC 14.1

GCC 14.1 官方历史源码包下载入口，适合旧项目兼容、编译环境回退、工具链验证、警告参数差异比对和 C/C++ 构建问题复现等场景使用。

下载

• 不把内部函数声明放进对外发布的头文件（public_api.h），外部代码就无法合法调用它
• 如果某 .o 文件中只有未被引用的全局函数，它会被链接器整个丢弃（ar 归档里留着，但不出现在最终 exe 中）
• 若外部代码误写了 extern int internal_function(); 并调用，链接会失败（undefined reference），除非你显式暴露了该符号的声明
• 静态库内部各 .o 之间可以自由互相调用（因为归档后仍保持目标文件粒度），无需额外导出标记

常见错误：试图用 visibility 控制静态库，结果反而破坏封装

有人会在构建静态库时加 -fvisibility=hidden，以为能“加固”，但实际会导致两个问题：

• 如果库内部多个 .c 文件之间通过非 static 全局符号互相调用（比如 helper.c 定义 int do_work();，main_logic.c 声明并调用它），加了 -fvisibility=hidden 后，这些跨文件调用会链接失败（undefined reference to 'do_work'）
• 这种做法混淆了“静态库内聚性”和“动态库接口隔离”的边界——前者靠模块划分和头文件控制，后者才靠 visibility

正确做法是：静态库内部用 static 限定所有不需跨文件使用的辅助函数；需要跨文件调用的，保持默认 visibility 即可，不需要额外干预。

想彻底杜绝内部符号泄露？靠 static 和头文件分层

最可靠、最轻量的隐藏方式，就是语言原生机制：

• 所有仅在单个 .c 文件内使用的函数/变量，一律加 static —— 它们连进入 .o 的全局符号表都不会，nm libxxx.a 根本看不到
• 对外提供功能的函数，只在公共头文件中声明，并确保其实现在对应 .c 文件中（不暴露实现细节）
• 内部模块间通信，使用私有头文件（如 internal.h），不随 SDK 一起发布
• 构建时用 ar rcs 打包，无需额外参数；链接时用 -lxxx，链接器自动裁剪未引用部分

真正的风险点不在编译或归档环节，而在于你是否不小心把 internal_*.h 一起发给了用户，或者在公共头文件里漏删了不该出现的 extern 声明。