std::bitset大小必须编译期确定，N需为常量表达式；operator[]返回proxy对象不可取地址；to_ullong()仅支持≤64位，超限抛overflow_error。
std::bitset 初始化时不能用运行时变量
编译期确定大小是 std::bitset 的硬性要求。你写 std::bitset<n></n>，N 必须是常量表达式；传个 int n = 8; 然后用 std::bitset<n></n> 直接报错：error: non-type template argument is not a constant expression。
常见错误场景：想根据用户输入或配置动态建位图，比如“读取文件行数后建等长 bitset”。这时候别硬扛，该换 std::vector<bool></bool> 或 std::vector<:uint8_t></:uint8_t> 就换。
- 真要编译期定大小？用字面量、
constexpr变量或模板参数 - 需要运行时长度？选
std::vector<bool></bool>（注意它不是标准容器，但支持位压缩）或手动分块管理std::uint64_t数组 -
std::bitset和std::bitset是两个完全不同的类型，没法用同一模板函数泛化处理
operator[] 返回的是 proxy 对象，不能取地址
std::bitset 的 operator[] 不返回 bool&，而是一个临时 proxy 类型（类似 std::vector<bool>::reference</bool>）。这意味着你不能对它取地址、不能绑定到 bool&、也不能用在需要左值的地方。
典型报错：error: cannot bind non-const lvalue reference of type 'bool&' to an rvalue of type 'std::bitset::reference'。
立即学习“C++免费学习笔记（深入）”；
- 写法错误：
bool& b = bs[3];→ 编译失败 - 正确写法：
bool b = bs[3];（读）或bs[3] = true;（写） - 如果真要批量操作某几位，用
set()、reset()、flip()带索引的重载，或者直接用位掩码配合to_ullong()/to_string()转出再处理
to_ullong() 在位数超限时会抛 std::overflow_error
std::bitset::to_ullong() 只能安全转换 ≤64 位的 bitset（unsigned long long 通常是 64 位）。哪怕你定义的是 std::bitset，调这个函数立刻崩溃，抛出 std::overflow_error。
这不是隐式截断，是明确拒绝——设计上就要求你意识到长度风险。
- 检查长度：
if (bs.size() - 跨平台更稳的做法：统一用
bs.to_string()转字符串，再按需解析；或用bs.to_ulong()（上限通常是 32 位，更窄但更可预期） - 性能敏感场景避免频繁调用
to_ullong()：它内部要遍历所有位，O(N)；不如维护一个缓存的整数值，手动更新
bitset 本身不支持位域式内存布局共享
有人想把 std::bitset 当作一个字节来用，直接 reinterpret_cast 成 uint8_t* 拿地址操作——不行。标准没保证 std::bitset 的内部存储是连续、无填充、可直接映射的字节序列。
实际中多数实现确实是紧凑存储，但这是实现细节，不是契约。靠这个写跨编译器/跨标准库的代码，迟早翻车。
- 需要裸字节访问？用
std::array<:uint8_t n></:uint8_t>手动管理，再封装 set/reset 逻辑 - 需要和硬件寄存器或网络协议对齐？必须用
std::uint8_t数组 + 显式位运算（&,|,, <code>>>） -
std::bitset的优势在语义清晰和编译期优化，不在内存布局可控性
位图容器选型本质是权衡：你要的是“写起来像布尔数组”还是“能精确控制每个比特在内存里的位置”。前者用 std::bitset，后者绕开它。
