不能直接模拟私有函数，因为c++无运行时反射且mock_method仅支持virtual成员；私有函数既不可继承也不可覆写，强行添加virtual或暴露为public均违背设计原则与语言限制。
不能直接模拟私有函数——C++ 没有运行时反射或“测试专用访问权限”，MOCK_METHOD 之类只能作用于 virtual 成员，而私有函数通常既不可继承也不可覆写。真要验证其行为，得绕开“模拟”这个错误目标，转向“隔离调用路径”或“重构暴露点”。
为什么不能对普通私有函数用 GoogleTest 的 MOCK_METHOD
MOCK_METHOD 要求被模拟的函数是 virtual 且声明在基类中，而私有函数天然无法被派生类重写，编译器会直接报错 error: cannot declare member function 'X::f()' to be virtual（如果强行加 virtual）或 error: 'X::f()' is private within this context（如果没加）。这不是配置问题，是语言限制。
- 私有 + 非虚 → 不可覆盖、不可注入、不可 mock
- 私有 + 虚 → 违反设计常理（谁会定义一个只在内部调用、又允许被覆写的函数？）
- 试图用
friend或#define private public去“暴露再 mock”，结果只是把私有函数变成公有后手动调用，不是模拟
真正可行的替代路径：把私有逻辑抽成独立可测试单元
与其纠结“怎么 mock 私有函数”，不如问：这个函数是否承担了单一、明确、无副作用的计算职责？如果是，它本就不该藏在类里。
- 将原私有函数逻辑提取为自由函数或
static inline函数，放在头文件中 - 保持原类中仅剩胶水代码（参数转发、状态检查、异常包装等）
- 测试时直接调用提取后的函数，无需任何 hack
- 示例：
class Parser中的parse_token()私有函数 → 提取为Token parse_token_raw(const std::string&)
这样做的好处是：不破坏封装、不耦合测试与实现细节、支持内联优化、且能被其他模块复用。
DLL 场景下必须测未导出私有函数？先确认是否真有必要
如果你的 DLL 只导出 __declspec(dllexport) 的公有接口，那测试工程根本链接不到私有函数地址；硬用 GetProcAddress 获取的是符号名（如 ?computeinternal@MathProcessor@@AAEHXZ），不仅不可读、易断，还绕过了编译期类型检查，不属于单元测试范畴。
- 优先验证导出函数的输入/输出、异常、副作用（如修改传入的
std::vector<t>&</t>） - 若某次公有函数测试失败，需定位到具体私有分支，此时应临时将 DLL 编译为静态库（
.lib），或把测试代码和源码放同一项目中编译，而非坚持 DLL + 单独测试工程 - Windows 下用
#define private public必须确保该宏只在测试 cpp 文件最顶部生效，且#include头文件前完成定义，否则可能污染其他依赖头文件
友元测试类：可控但需谨慎引入
在极少数无法重构、又必须白盒验证逻辑的场景下，friend class TestMathProcessor; 是编译器原生支持的方案，比宏 hack 更安全。
- 友元声明只影响访问控制，不改变 ABI，DLL 导出行为不受影响
- 测试类名写死在产品头文件里，意味着每次改测试名都要动生产代码 —— 建议约定命名如
MathProcessor_TestAccess并长期固定 - 不要在友元类里写业务逻辑，只提供窄接口：例如
int MathProcessor_TestAccess::call_computeinternal(MathProcessor& p) - 注意：友元不传递，
TestMathProcessor的派生类无法自动获得访问权
真正难的不是技术手段，而是判断哪一段私有逻辑值得单独验证——多数时候，它只是公有接口行为的中间产物，而非独立契约。暴露它，往往说明职责划分已经模糊。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
