std::forward_list无size()是设计选择而非缺陷，判空必须用empty()；insert_after/erase_after参数必须为前驱迭代器；splice_after是唯一不可替代的O(1)拼接操作。
std::forward_list 没有 size() 不是缺陷，是设计铁律；用错 insert_after() 或 erase_after() 的参数，90% 以上会删错节点或触发未定义行为；splice_after() 是它唯一不可替代的性能支点——其他操作都能被替代，这个不能。
为什么 size() 绝对不能信，连判空都不行
libstdc++（GCC 默认 STL）至今不维护计数器，fl.size() 就是 std::distance(fl.begin(), fl.end())，纯 O(n) 遍历。C++17 要求可实现为 O(1)，但你项目大概率还在 C++14 或嵌入式裁剪版里。更危险的是：fl.size() == 0 在某些旧实现上可能返回垃圾值、抛异常，甚至根本没定义该函数。
- 判空唯一可移植写法：
fl.empty()，它始终 O(1) 且 guaranteed defined - 临时需要长度：只调一次
std::distance(fl.begin(), fl.end())，结果存局部变量复用 - 高频访问长度：手动维护一个
size_t count，每次push_front()、insert_after()、erase_after()后同步增减 - 禁止在循环条件里写
for (size_t i = 0; i < fl.size(); ++i)—— 这会让 O(n) 变成 O(n²)
insert_after() 和 erase_after() 的参数永远指“前驱”，不是目标节点
这是单向链表结构决定的硬约束：没有 prev 指针，就无法从任意节点反推前驱。所有中间操作必须显式传入前驱迭代器，否则就是未定义行为。
- 头插安全写法：
fl.insert_after(fl.before_begin(), x)或更简洁的fl.push_front(x) - 删首节点：
fl.erase_after(fl.before_begin())；传fl.begin()给erase_after()实际删的是第二个元素 - 删第 n 个元素（n ≥ 1）：
auto prev = std::next(fl.before_begin(), n - 1)，再fl.erase_after(prev)—— 注意是n - 1，不是n - 遍历时删当前匹配节点：初始化
auto prev = fl.before_begin()，循环内用auto curr = std::next(prev)定位，匹配后执行prev = fl.erase_after(prev)跳过被删节点 - 绝不可传
fl.end()给任一函数 —— 结果未定义
为什么 splice_after() 是唯一值得手写的高性能操作
splice_after() 是 std::forward_list 唯一真正 O(1) 的物理拼接操作：不调用构造/析构、不分配内存、不拷贝数据，只改 next 指针。其他任何模拟方式（比如循环 insert_after()）都会彻底毁掉它的内存与性能优势。
立即学习“C++免费学习笔记（深入）”；
- 整体迁移：
dst.splice_after(pos, src)，拼接后src变为空容器 - 单节点迁移：
dst.splice_after(pos, src, it)，把src中it所指节点移到dst - 区间迁移：
dst.splice_after(pos, src, first, last)，只拼接[first, last)（左闭右开）范围 - LRU 缓存中把命中节点提到头部：
fl.splice_after(fl.before_begin(), fl, it)，注意要配合手动维护头尾逻辑 - src 和 dst 必须同类型，且不能是同一对象（自拼接未定义）
什么时候该用 std::forward_list，什么时候该立刻换掉
它不是 “更轻量的 std::list”，而是为极端场景定制的取舍型容器：用放弃反向遍历、随机访问、O(1) size、尾部操作，换每节点少存一个指针（64 位下省 8 字节）。这只有在「节点数量大 + 值类型小 + 操作模式严格匹配」时才真省内存、真高效。
- 适合：
std::forward_list<int>存 10⁵ 个以上节点；哈希桶里平均长度 ≤ 3 的短链表；裸机/嵌入式内存极度敏感场景 - 不适合：
std::forward_list<std::string>或大结构体（8 字节差异可忽略）；需要back()、rbegin()、operator[]；频繁查长度或按索引访问 - 实测建议：用
sizeof看你的实际节点大小，allocator 对齐可能影响结果；别依赖文档或经验 - 一旦出现性能异常、未定义行为或省内存效果不明显，优先检查是否误用了
size()、传错了迭代器，或场景根本不匹配
