代码块本身不创建作用域，但配合let/const声明与显式{ }包裹可隔离变量；状态机中应按语义单元分块，用短名表临时变量、state_前缀表跨块状态，使变量边界与业务边界对齐。
代码块（Code Block）本身在 JavaScript、C、C++、Java 等主流语言中并不创建独立的作用域（ES6 之前 var 声明仍受函数作用域约束），但用 { } 包裹的块级结构配合 let/const（ES6+）、if(true) { }、do { } while(0)（C/C++）等技巧，可有效隔离临时变量，避免复杂状态机中命名冲突和意外覆盖。关键不在“语法块”，而在“声明方式”与“结构意图”的协同。
用 let/const 替代 var，在显式块中定义临时变量
在状态机每个分支或子流程中，用 { } 显式包裹逻辑，并仅用 let 或 const 声明该段专用变量：
- 避免把所有中间变量堆在函数顶部，防止跨状态误读或重赋值
- 例如：在
case 'PROCESSING':分支内写{ const retryCount = 3; const timeoutId = setTimeout(...); /* ... */ }，退出块后变量自动不可访问 - 即使状态反复进入该分支，每次都是全新绑定，无残留风险
用 IIFE（立即执行函数）或 do-while(0) 封装 C/C++ 风格状态段
在不支持块级作用域的老环境或 C/C++ 中，需主动构造作用域边界：
- JavaScript 可用
(function() { let tmp = compute(); handle(tmp); })();—— 形成闭包，tmp 不泄漏 - C/C++ 推荐
do { int step_flags = 0; parse_header(&step_flags); } while(0);—— 语义清晰、可带 break、变量生命周期严格限定在块内 - 比裸写
{ int x; ... }更健壮，尤其在宏定义或条件编译中不易出错
状态机中按“语义单元”划分代码块，而非仅按 switch/case
一个 case 可能包含多个逻辑阶段（如校验 → 转换 → 提交），每个阶段应有独立块：
- 例如：
case 'SUBMIT': { const valid = validate(data); if (!valid) break; { const payload = transform(data); send(payload); } } - transform 阶段的
payload、headers等不会与 validate 阶段的errors、context冲突 - 块名无需注释，但建议在块前加单行注释说明目的，如
// 构建网络请求体
命名策略配合作用域：小范围用短名，跨块用带状态前缀的长名
作用域隔离后，命名可更聚焦语义，减少冗余：
- 块内临时变量：用
tmp、res、idx等简洁名（因生命周期短、上下文明确） - 需跨多个块传递的状态量（如错误码、重试计数）：统一用
state_*前缀，如state_retryCount、state_lastError，明确其“存活于整个状态机实例” - 禁止出现
data1、tempVar这类无意义名称，哪怕在块内也应体现用途
不复杂但容易忽略：作用域隔离不是为了炫技，而是让每个变量的“可见边界”与“业务边界”对齐。状态机越复杂，越要靠结构化块 + 精准声明 + 语义化命名，把隐性依赖变成显性约束。
