我最不想维护的代码。
往往不是大模块。
而是那种。
“就几行”的工具函数。
因为大家都觉得它简单。
简单就没人测。
没人测就会藏坑。
当年：每个项目都有一份 clamp/gcd，但每份都不太一样
你肯定写过 clamp。
把值限制在某个范围。
int clamp_old(int x, int lo, int hi) {
if (x < lo) return lo;
if (x > hi) return hi;
return x;
}
它能用。
但它有边界。
比如 lo > hi 怎么办？
比如类型是浮点怎么办？
比如你写错了比较符号怎么办？
这类 bug 很无聊。
但线上啪一下时也很恶心。
线上啪一下：限流参数写错边界，结果把所有请求都当成“超限”
假设你写了个小服务。
有个 QPS 限制。
你要把配置值夹在 [1, 1000]。
你手写 clamp。
某天写成了。
if (x > hi) return lo;
就这么一个手滑。
线上直接把 QPS 限制夹成 1。
服务像被掐住脖子。
C++17：std::clamp
#include <algorithm>
int x = std::clamp(cfg, 1, 1000);
这行读起来很像英语。
clamp 到 1..1000。
它也把“实现细节”从你项目里拿走。
你不必每次重写。
gcd/lcm：看起来是数学题，其实是工程题
你在做分片。
做周期任务。
做分辨率对齐。
很容易遇到最大公约数/最小公倍数。
以前你要么手写欧几里得。
要么 copy 一段。
copy 来的那段可能对 0 的处理还不一致。
std::gcd
#include <numeric>
int g = std::gcd(a, b);
它能帮你写更稳的“约分”。
比如把一个比例化简。
std::lcm
#include <numeric>
int p = std::lcm(10, 15); // 30
在定时任务里很常用。
比如两个周期任务。
你想知道它们多久会对齐一次。
关键结论
这些小函数进标准库的意义是。
少写一份“看似简单但容易错”的工具代码。
小结：把小坑交给标准库，别让它们在你项目里繁殖
工程里最烦的不是大坑。
大坑你会盯着。
最烦的是小坑。
它们散在各处。
等你线上出事时。
你要翻很多角落。
C++17 把 clamp/gcd/lcm 放进来。
你就少一个角落。