随着设备复杂度提升，三菱GX Works3支持的结构化文本（ST）语言正逐渐取代梯形图，成为中大型项目的主力。然而，许多从梯形图转型的工程师常犯“换汤不换药”的错误，导致代码冗长、执行效率低下。本文基于三菱FX5U和Q系列项目实战，总结出六大ST编程陷阱与破解之道。

陷阱一：滥用FOR循环处理位操作。在梯形图中，工程师习惯用置位/复位指令控制单个输出点。在ST中，直接对数组元素逐位赋值虽然可行，但会浪费扫描周期。更优方案是使用“字节映射”技巧：例如将16个输出点定义为一个INT变量，通过位运算（如BOR、BSET）一次性更新。某包装机项目曾因在ST中写了16行REPEAT循环，导致扫描周期从2ms暴涨至15ms，重构后恢复至2.5ms。

陷阱二：忽视CASE语句的优先级。与梯形图的互锁逻辑不同，CASE语句是按顺序执行的。很多工程师在编写多状态机时，将状态判断条件写得过于“宽松”，导致高优先级状态被低优先级状态覆盖。正确做法是，在每个CASE分支末尾加上显式的“RETURN”或使用“EXIT”退出，防止状态穿透。

陷阱三：对FB（功能块）内部变量作用域理解不足。在ST中，FB内部变量默认是“实例专用”的，但如果误将临时变量声明为“VAR_GLOBAL”，在多实例调用时会引发数据竞争。例如，一个PID控制FB被用于控制两个气缸，若积分项变量被误设为全局，两个气缸的压力会相互干扰。务必在每个FB实例化时，通过“VAR_IN_OUT”显式传递外部接口。

陷阱四：过度依赖指针。三菱ST支持指针，但滥用会导致程序极难调试。建议仅在与外部设备（如触摸屏）进行大量数据交换时使用指针，对于内部逻辑，直接引用变量名即可。

陷阱五：忽略负数与无符号数转换。当从模拟量模块读取数据时，原始值是带符号的INT，但工程值可能是百分比。直接做除法运算会丢失符号位。正确的做法是先转换为REAL类型，再进行运算。

陷阱六：注释与命名不规范。ST语言的可读性完全依赖命名。建议采用“匈牙利命名法”加“动作前缀”的组合，如“bMotorRunCmd”，既表明类型又表明用途。