布尔变量应源自可验证事实而非硬编码，需结合枚举与状态机建模，并善用逻辑运算符短路特性实现安全控制。
布尔变量不是“开关本身”，而是对真实状态的表达结果；真正有效的逻辑控制，必须让布尔值从可验证的事实中动态生成，并与清晰的状态结构绑定。硬编码 true 或 false 会切断上下文，导致后续判断失效、维护困难。
用事实驱动布尔值，而非手动赋值
布尔状态应来自运行时可观测的输入或条件，而不是静态设定：
- 表单提交前：用 form.isValid && !isSubmitting 生成 canSubmit，而非直接写 canSubmit = true
- 设备控制中：读取引脚电平 digitalRead(13) === HIGH 得到 isLedOn
- 网络就绪判断：调用 ping('api.example.com') !== null 输出 isConnected，避免假连通
善用逻辑运算符的短路行为做安全守门
&& 和 || 不只是计算真假，更是流程控制的“闸门”：
- device && device.powerOn()：先确保 device 存在，再执行方法，避免空指针报错
- user.role === 'admin' && renderAdminTools()：权限不满足时跳过敏感操作，不触发副作用
- config.timeout || 5000：为配置项提供默认值，比三元表达式更简洁（注意：0、''、false 会被覆盖）
用布尔+枚举组合建模，替代堆砌标志位
多个布尔变量拼凑（如 start_flag && !stop_flag && dir == 1）会迅速失控。工业级做法是：
- 用布尔控件感知信号：比如 isEmergencyPressed、isOverheated，只反映单一物理/业务事实
- 用枚举定义主状态：如 MotorState.IDLE / RUNNING / STOPPING / FAULT_RECOVERY
- 用有限状态机（FSM）组织转移逻辑：每个状态明确 entry/during/exit 行为，转移条件写在箭头上（如 [isEmergencyPressed]），不散落在 if 块里
在 UI 层用单选组构建 CSS 状态机
当状态超过两种（开/关），复选框技巧就失效了。单选按钮组天然适合表达互斥状态：
- 每个 代表一个确定状态（如 view=dashboard、view=reports、view=settings）
- 通过 :checked + .panel 等 CSS 选择器驱动样式切换，无需 JS 即可实现完整状态响应
- 整个 radio 组即是一个轻量级状态机——它强制唯一选中，天然防止非法状态（如同时激活 dashboard 和 settings）
