使用ERR陷阱时，如何合理处理Shell算术表达式？

我遇到了一个反直觉的Bash语法问题，先看这段代码：

#!/bin/bash

trap 'echo>&2 "~ trapped on $? ~"' ERR

declare -i i=0

while ((i < 10)); do
    printf "%d " $i
    ((i++))
done

echo

运行后输出超出预期，触发了ERR陷阱：

0 ~ trapped on 1 ~
1 2 3 4 5 6 7 8 9

原因很明确：(( ))算术表达式的规则是，内部求值结果为0时，会返回退出码1；非0则返回退出码0。这里用了后置自增i++，第一次循环时((i++))求值为0（取i自增前的初始值0），导致退出码为1，触发了ERR陷阱。换成++i或i+=1就能避免，但这种行为实在不符合直觉。

我常常用((ecode=$?))来保存上一条命令的退出码，比如：

true; ((ecode=$?))
echo "working with $ecode here"

但这里true返回退出码0，((ecode=$?))的求值结果是0，对应的退出码为1，反而触发了陷阱——触发点是算术表达式本身，而非之前的true命令。

我试过用true || ((ecode=$?))，但这只在命令返回非零时才赋值，而我需要的是：命令返回非零时触发陷阱，同时ecode能保留上一条命令的结果（不管是0还是非0）。每次执行前清零ecode反而更麻烦。

目前找到的最佳写法是! ((ecode=$?))，这样既不会触发陷阱，又能正确完成赋值。

实际场景中我需要的不只是单纯赋值，比如((eflag|=(elast=$?)))——这样可以在命令块中记录所有错误（eflag只要有一次错误就会保持非0），同时保留最后一条命令的退出码（elast）。后续可以根据情况用! ((elast)) &&或! ((eflag)) &&来启动逻辑，可读性还过得去。

为什么不用if; then; else结构？因为这样会丢失代码上下文，还会阻止陷阱触发——而ERR陷阱原本可以捕获$BASH_COMMAND等有用信息并写入日志，方便后续排查，且不会干扰用户操作。

难道只能一直用这种! ((...))的写法吗？现在任何独立的算术表达式都像是潜在的陷阱触发点。有没有更好的实践方法，能避开这种Shell特有的语法坑？

内容的提问来源于stack exchange，提问作者Albert Camu