位域受类型和对齐约束，相邻同类型位域可打包，跨类型或跨界会插入填充；顺序依赖编译器与平台；硬件映射需volatile+显式对齐；位域不可取地址、不能为数组元素；跨平台位序不保证，应避免依赖自动打包。
位域声明语法和对齐规则
位域不是任意指定宽度就能生效的，它受所在整型类型和编译器对齐策略约束。struct 中相邻位域若类型相同且总宽未超该类型的位数，通常会被打包进同一个存储单元；一旦类型改变或跨界，编译器可能插入填充位。
-
unsigned int a : 3;和unsigned int b : 5;很可能共用一个unsigned int（共 8 位） -
unsigned int a : 3;后跟unsigned short b : 4;，则b很可能从新short起始地址开始，前面浪费 13 位 - 标准不保证位域在内存中从左到右还是右到左排列，实际顺序依赖编译器和目标平台（如 x86 vs ARM）
硬件寄存器映射时必须用 volatile + 显式对齐
直接把位域结构体映射到硬件寄存器地址是常见做法，但若不加 volatile，编译器可能优化掉多次读写；若没强制对齐，结构体大小或字段偏移可能与硬件要求错位。
struct CAN_TxMailBox {
volatile uint32_t TDTR : 8; // 发送时间戳
volatile uint32_t TDLR : 16; // 低 16 位数据
volatile uint32_t TDHR : 8; // 高 8 位数据
} __attribute__((packed, aligned(4))); // GCC 方式：禁用填充 + 4 字节对齐
-
volatile必须加在每个位域前，否则对单个字段的读写可能被优化 -
__attribute__((packed))防止编译器自动填充，但会降低访问性能；某些平台（如 Cortex-M3）要求寄存器访问必须自然对齐，此时需配合aligned(N) - ARM CMSIS 头文件中常用
__IO宏替代volatile，语义更明确
位域不能取地址，也不能是数组元素
这是最容易踩的坑：位域字段没有内存地址，因此无法对其使用 & 运算符，也不能放在 std::vector 或作为函数参数按引用传递。
- 以下代码非法：
&s.a（s是位域结构体变量），编译器报错cannot take the address of a bit-field - 想批量操作多个同类位域？得改用普通整型 + 手动位运算：
uint16_t flags;配合(flags >> 3) & 0x07 - 调试时观察位域值，GDB 可能显示不准确——因为实际布局依赖编译器实现，建议用
union封装位域+原始整型来交叉验证
跨平台移植时位序和大小端不可靠
同一个位域定义，在不同架构上可能解析出完全不同的值。比如 struct { uint8_t a:4, b:4; }; 在某些编译器中 a 占高 4 位，b 占低 4 位；另一些则相反。
立即学习“C++免费学习笔记（深入）”；
位域节省的是结构体整体尺寸，但换来的是可移植性折损和调试复杂度上升；硬件驱动中它有用，但仅限于你完全掌控编译器、目标架构和内存映射细节的场景。
