用std::map实现带过期键值容器的核心是存储key→{过期时刻,值}，插入时用steady_clock计算过期时间，读取前必须检查当前时间是否早于过期时刻，避免返回过期数据。
如何用 std::map + 时间戳实现带过期的键值容器
核心思路是把键值对和过期时间一起存，每次访问前检查时间戳。不用引入第三方库，std::chrono 就够用。
常见错误是直接用 time_t 或秒级精度导致并发下多个条目同一秒过期时清理不及时；或者在读操作里不做时间判断，导致返回已过期数据。
- 用
std::map<:string std::pair std::string>></:string>存储：key → {过期时刻, 值} - 插入时用
std::chrono::steady_clock::now() + std::chrono::seconds(60)计算过期点（推荐steady_clock，不受系统时间调整影响） - 读取时先比对
now() ，不满足则主动 <code>erase()并返回空或抛异常 - 避免在
operator[]中隐式插入——它会绕过过期检查，改用显式get()方法
为什么不能直接继承 std::unordered_map 并加定时器
定时器轮询清理听着合理，实际容易出问题：线程安全难保障、空转耗 CPU、过期间隔难控制精度。更糟的是，如果容器本身没封装清理逻辑，外部调用方根本不知道某个 key 已逻辑过期但物理还存在。
典型现象是：多线程写入后，某次 find() 返回了迭代器，但解引用时值已失效（因为另一线程刚触发了过期清理，而你没同步）。
立即学习“C++免费学习笔记（深入）”；
- 别用
std::thread启一个后台清理循环——它需要锁整个 map，读写吞吐暴跌 - 别依赖
std::alarm或信号——C++ 标准库不保证信号安全，且无法精准绑定到容器生命周期 - 真正轻量的做法是“惰性清理”：查、删、改都顺便清理邻近过期项（比如遍历前 5 个检查是否过期），不额外开销
erase_if_expired() 的安全遍历写法
用 erase() 删除迭代器时，必须小心失效问题。常见翻车写法：for (auto it = m.begin(); it != m.end(); ++it) 里直接 erase(it) —— 迭代器立刻失效，++ 操作未定义行为。
正确做法是使用 erase() 返回的下一个有效迭代器，或者分两步：先收集待删 key，再批量 erase。
auto now = std::chrono::steady_clock::now();
for (auto it = m.begin(); it != m.end(); ) {
if (it->second.first <= now) {
it = m.erase(it); // erase 返回下一个迭代器
} else {
++it;
}
}
- 不要用
std::remove_if配合erase——std::map不支持随机访问，remove_if无效 - 如果容器很大，一次全扫太重，可限制单次最多删 10 个，避免阻塞调用方
- 注意
steady_clock::time_point比较是常数时间，不用担心性能
如何让过期策略可配置（TTL / 固定到期时间）
硬编码 60 秒很不灵活。实际业务中有的要按绝对时间过期（如 token 绑定 JWT exp 字段），有的要相对 TTL（如缓存 10 分钟）。接口设计得区分清楚。
容易忽略的是：不同 key 可能需要不同过期策略。若统一用 TTL，就无法支持“这个 session 永不过期，那个临时码 30 秒后作废”这种混合场景。
- 构造函数接受一个
std::function<:chrono::steady_clock::time_point std::string key></:chrono::steady_clock::time_point>，由用户决定每个 key 的过期时刻 - 提供两个便捷构造：一个传
std::chrono::seconds（自动算相对时间），一个传std::chrono::steady_clock::time_point（绝对时间） - 避免把过期逻辑塞进 value 类型里——那样序列化/拷贝成本高，且破坏单一职责
最麻烦的其实是时钟偏移：如果服务部署在多台机器上，各自本地时钟有毫秒级偏差，用绝对时间过期可能造成部分节点提前丢数据。这时候就得上 NTP 对齐，或者干脆只用相对 TTL。
