std::bitset模板参数是编译期确定的位宽而非字节数，初始化须用常量表达式，推荐字符串或整数字面量；操作优先用set()/reset()/flip()而非operator[]；to_ulong()等需先检查size()防溢出。
bitset 初始化时要注意模板参数是位数，不是字节数
很多人误以为 std::bitset 表示“8 字节”，结果发现只能存 8 个 bit，最大值才 255。它第一个模板参数是**编译期确定的位宽**，不是类型大小。比如要模拟一个 uint32_t 的位操作，得写 std::bitset，而不是 std::bitset。
常见错误现象：bitset b = 0xFF; 编译失败或静默截断为 1111（即 15），因为只留低 4 位。
- 初始化推荐用字符串或整数字面量：
bitset{"10101010"}或bitset{170} - 不能用运行时变量直接构造：
int n = 8; bitset<n> b;</n>❌ 不合法，模板参数必须是常量表达式 - 若位宽不确定，考虑用
vector<bool></bool>或手动管理uint64_t数组
用 set()、reset()、flip() 比直接操作 operator[] 更安全
operator[] 返回的是代理引用（proxy reference），不能取地址，也不支持链式调用；而 set() 等成员函数语义清晰、可读性高，且编译器对它们做了充分优化。
使用场景：批量置位、清零、翻转某几位，尤其在配置寄存器或协议解析中很常见。
立即学习“C++免费学习笔记（深入）”；
-
b.set(3)→ 第 3 位（从 0 开始）设为 1 -
b.reset(3)→ 第 3 位清 0 -
b.flip(3)→ 第 3 位取反；不带参数则全部翻转 - 避免写
b[3] = true;后又想&b[3]—— 这会编译失败
to_ulong() 和 to_ullong() 有溢出风险，务必先检查 size()
当 bitset 位宽超过目标整型能表示的范围时，to_ulong() 会抛 std::overflow_error。比如 bitset.to_ulong() 在大多数平台必然失败（unsigned long 通常最多 64 位）。
错误现象：程序在某些输入下突然 terminate，堆栈里看到 std::overflow_error。
- 安全做法：先用
b.size() 判断，再调用 <code>to_ulong() - 更通用方案：用
to_string()转字符串再进制转换，或用boost::multiprecision处理大位宽 -
to_ullong()也只是扩展到unsigned long long，仍非任意精度
性能关键点：bitset 是栈上固定大小对象，避免频繁拷贝大 bitset
std::bitset<n></n> 的大小在编译期就确定了（通常是 (N+7)/8 字节向上对齐），所有操作都是内联、无动态分配。但 N 很大时（比如 bitset），拷贝开销明显，传参建议 const 引用。
兼容性影响：GCC/Clang/MSVC 都完全支持，但部分老标准库（如 libstdc++ 早期版本）对 > 64 位的 to_*() 实现有 bug。
- 传参别写
void f(bitset b)，改用void f(const bitset& b) - 不要用
auto b = bitset{};然后反复赋值——每次赋值都是内存块拷贝 - 若需动态位长 + 高性能，
std::vector<bool></bool>是空间优化特化，但访问慢；std::vector<uint64_t></uint64_t>手动位运算反而更快
实际项目里，bitset 最适合做编译期可知宽度的标志位集合、状态机编码、哈希布隆过滤器的小规模实现。一旦涉及运行时长度、跨平台序列化或超 1024 位，就得切换思路——它不是万能位容器，只是 C++ 给你的一把精准小镊子。
