结论：全局函数应依“谁用、为什么用、改了影响谁”划分模块，优先归入命名空间下的自由函数；仅当与特定数据强绑定时才封装为类成员函数；避免滥用utils大杂烩和static成员函数，同步更新头文件依赖。
直接说结论：别硬塞进一个类，先按“谁用、为什么用、改了影响谁”切模块，再把函数归到对应类的public静态成员或自由函数+命名空间里。强行打包成单个“Utils”类，只会让坏味道从全局蔓延到类内部。
识别哪些全局函数真该进类，哪些就该留在命名空间里
不是所有全局函数都适合变成成员函数。关键看它和数据有没有强绑定：
- 如果函数只操作传入参数（比如
std::max、is_valid_email），没读写任何隐式状态——它天生就是自由函数，放进命名空间比塞进类更干净； - 如果函数总在操作某组固定变量（比如
g_player_hp、g_game_speed），且这些变量逻辑上属于同一实体——那它们应该一起封装进Player或GameConfig类，函数变成员函数； - 如果函数调用链里反复传递同一组参数（比如
config、logger、db_conn），说明它其实依赖隐式上下文——这时更适合提取为一个类（如ReportGenerator），把参数变成员变量，函数变方法。
命名空间不是摆设：用嵌套命名空间替代“Utils”大杂烩
很多人把所有工具函数扔进namespace Utils，结果Utils::clamp、Utils::parse_json、Utils::send_http混在一起，职责依然模糊。正确做法是按领域分层：
- 把数学相关函数放进
namespace math（math::lerp、math::distance_sq）； - 把字符串处理放进
namespace str（str::split、str::to_upper）； - 把平台适配函数放进
namespace os（os::get_exe_path、os::sleep_ms）； - 必要时再加一层业务前缀，比如
namespace game::net，避免跨域污染。
这样别人看到game::net::pack_packet，不用点进去就知道它干啥，也不怕和tools::pack_file冲突。
静态成员函数 vs 自由函数：选错会锁死扩展性
把函数塞进类当static成员，看似“归类”了，但实际埋了坑：
-
static成员函数无法被ADL（Argument-Dependent Lookup）发现，调用时必须写全名ImageLoader::decode_jpeg(...)，没法像自由函数那样靠参数类型自动找到； - 它绑死了所属类，以后想把
decode_jpeg抽成独立库、或支持插件式解码器时，得动接口、改调用方； - 真正该用
static的，只有那些明确属于类生命周期管理的函数，比如Texture::create_from_file（创建本类实例）、Logger::set_level（控制本类全局行为）。
其余多数情况，优先用自由函数 + 命名空间。C++标准库也是这么做的：std::sort不是std::vector::sort，std::make_shared也不是std::shared_ptr::make。
最容易被忽略的一步：同步更新调用点的头文件依赖
整理完函数归属，很多人只改定义，不改#include。结果原来#include "utils.h"的地方，现在要分别#include "math/clamp.h"、#include "str/split.h"——但没人告诉调用者。这会导致：
- 编译失败（找不到符号），尤其在头文件未显式包含依赖时；
- 隐式依赖残留（靠某个中间头文件间接包含了旧
utils.h），一旦中间头删了就崩； - 构建时间变长（
utils.h可能被上百个文件包含，而math/clamp.h只被5个用到）。
所以整理后，必须用grep -r "Utils::" src/或IDE的“查找所有引用”，逐个修正调用点的#include和命名空间使用方式。这步不做，等于白重构。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
