复合赋值运算符不是语法糖，而是语义明确的原地更新：*=、/=、+=等表达“用当前值参与运算后直接写回原变量”的不可分割动作，在循环累乘、指数衰减等场景更清晰安全。

复合赋值运算符不是语法糖，而是语义明确的原地更新

直接说结论：*=、/=、+= 等不是为了“省字符”，而是表达「用当前值参与运算后，把结果直接写回原变量」这一不可分割的动作。这在循环累乘、指数衰减、滑动平均等场景中天然贴合逻辑，比 x = x * factor 更清晰且更安全。

常见错误是把它当成纯缩写，结果在浮点或引用类型上出问题。比如对 list 用 += 和 = x + y 行为完全不同——前者调用 __iadd__ 原地扩展，后者新建对象。

• Python 中 arr += [1,2] 修改原列表；arr = arr + [1,2] 创建新列表，性能差且可能破坏外部引用
• JavaScript 的 num /= divisor 等价于 num = num / divisor，但若 divisor 为 0，两者都抛 Infinity 或 NaN，无差别
• C/C++ 里 a *= b 可能触发整数溢出未定义行为，和分开写一样危险，不减少风险

哪些场景用 *= 或 /= 能真正简化逻辑

核心判断标准：是否需要「基于当前状态连续缩放」。不是所有乘除都适合——只有当因子本身依赖上下文（比如随时间衰减、按步长增长），且每次都要覆盖旧值时，*= 才让意图一目了然。

• 实现指数移动平均：ema *= alpha; ema += (1 - alpha) * new_value —— 比先算 ema = ema * alpha 再加，少一次重复写变量名，也避免手误写成 ema = ema * beta
• 控制动画缩放比例：scale *= 1.05 表达“每帧放大 5%”，比 scale = scale * 1.05 更紧凑，也防止漏掉 scale 右侧的拼写错误
• 数值积分步进：dt /= 2 表示“时间步长减半”，语义比 dt = dt / 2 更贴近物理含义

容易踩的坑：类型隐式转换和精度丢失

/= 在整数上下文中尤其危险。Python 3 里 x //= y 是整除，x /= y 却一定返回 float —— 如果你本意是保持整数精度，用错就引入浮点误差。

• Python：n /= 2 把整数 n 变成 float，后续再 int(n) 会丢精度；该用 n //= 2 就别用 /=
• JavaScript：let x = 5; x /= 2; 得 2.5，但若业务要求向下取整，得显式 x = Math.floor(x / 2)，不能靠 /= 隐含意图
• Go 不支持 /= 对整型变量（编译报错），强制你意识到类型约束，反而是好事

替代方案比复合赋值更合适的情况

当运算涉及多个变量、条件分支或需保留原始值时，硬套 *= 反而增加理解成本。这时候老老实实拆开写，反而更直白。

• 计算带权重的归一化：result = (a * w1 + b * w2) / total_weight —— 拆开比强行写成 a *= w1 再加 b *= w2 清晰得多
• 条件缩放：if flag { x *= 0.9 } else { x *= 1.1 } 看似合理，但若 flag 逻辑复杂，不如先算因子 factor = flag ? 0.9 : 1.1，再 x *= factor，可读性更高
• 需要原子性保障的并发场景：复合赋值不是原子操作（如 x *= y 本质是读-算-写三步），多线程下必须加锁，此时显式拆解反而便于插入同步点

真正省事的地方，是它准确表达了「就地、连续、单变量驱动」的意图；一旦这个前提不成立，就别为了形式简洁牺牲可维护性。