Bash 脚本给 UID 赋值时报 readonly variable

脚本把导入记录中的用户标识赋给 UID，运行时却报 UID: readonly variable。这条错误发生在 shell 变量赋值阶段，尚不能说明输入文件损坏或目标账户没有权限。

在 Bash 中，UID 是启动时初始化的只读变量，表示当前用户的用户 ID。自定义字段碰上了这个名称。下面针对 Bash，包括 Bash 5.2；不能假定所有名为 sh 的解释器都具有相同变量集。

改自定义变量名，并同步所有引用

例如，下面的赋值会与 Bash 的内建变量冲突：

UID='account-001'

如果它代表导入数据的账户标识，可改成有明确用途的名称。这个完整小例子只打印测试值，不创建账户：

#!/bin/bash
input_account_id='account-001'
printf '%s\n' "$input_account_id"

真实脚本里应同时替换读取、赋值和传给后续命令的引用。只改赋值左侧，调用位置仍写 $UID，就可能继续把当前运行用户的数字 ID 当成业务账户标识。批量创建账户或更新数据前，应先用无敏感测试记录核对参数，不能只以错误消失为通过。

小写且带用途前缀的名称能减少冲突，但不是“所有小写变量都绝对安全”的保证。还要检查脚本已使用的局部变量、导入配置和环境约定；不要对包含 UID 的所有文本做无差别替换。

如果代码本来就是要判断运行身份，应保留读取 UID 的含义。有效用户 ID 对应另一个只读变量 EUID，两者不要拿来存放外部输入：

printf 'UID=%s EUID=%s\n' "$UID" "$EUID"

把一个数字写进变量不能改变进程的系统身份。用 sudo 重新运行也不会让 Bash 的只读变量变成可写；为了绕过这个赋值错误提升权限，会让后续业务操作在更高权限下运行，却没有修复名称冲突。

同一份脚本可能在一台机器由其他 shell 读取，另一台由 Bash 读取。首行、手工命令、计划任务和外层包装都要对应核对，不能只看交互终端的登录 shell。

若已确认是 Bash，可在不输出业务数据的位置读取 BASH_VERSION，确认当前实例的版本。不要为这一个变量名冲突更换系统 /bin/sh，也不要为了保留 UID 自定义赋值而切换解释器；其他语法和运行行为可能随之改变。

修复范围通常只是脚本内部变量名。保存原版本，在测试入口核对输入标识确实传到预期参数，再恢复正常任务。若先前的失败发生在批量处理中，先确认哪些记录已经执行，按业务去重规则接续；恢复代码不会撤销已创建的账户或已提交的数据。