-fvisibility=hidden对静态库无效，因其仅作用于动态库的符号导出，而静态库靠链接时按需提取和头文件设计实现隐藏；真正起效的是static关键字与头文件分层控制。
静态库本身不导出符号，所以“隐藏内部实现”不是靠编译选项控制的，而是靠链接时的按需提取机制和头文件设计决定的。 你无法用 -fvisibility=hidden 或 __attribute__((visibility("hidden"))) 影响静态库的符号可见性——这些只对动态库（.so / .dylib）生效。
为什么 -fvisibility=hidden 对静态库无效
静态库（.a）只是多个 .o 文件的归档，不经过动态链接器，也没有运行时符号表。链接器（ld）在处理 .a 时，只提取其中**被引用到的目标文件**，未被调用的函数/变量根本不会进入最终可执行文件。这意味着：即使你在 internal_function.c 里定义了一个全局函数，只要主程序没调用它，它就不会出现在最终二进制里。
所以，-fvisibility=hidden 这类控制“动态符号导出”的开关，在静态归档阶段毫无作用——它压根不参与符号导出流程。
真正起作用的是头文件 + 链接顺序 + 符号引用关系
静态库的“隐藏”效果，完全依赖于你是否让外部代码能声明并调用某个符号。关键点如下：
- 不把内部函数声明放进对外发布的头文件（
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 声明。
