local 必须在函数内声明才生效，脚本顶层使用会被忽略；它实现变量遮蔽而非修改，退出后自动销毁；支持属性修饰但需注意 -i/-r 的陷阱；调试应使用 declare -p 查看作用域。
local 必须在函数体内声明，且不能用于全局作用域
直接在脚本顶层（函数外）写 local var=value 不会报错，但会被 Bash 忽略——变量仍会变成全局变量。这是最常被误用的点。只有在函数内部使用 local，它才真正生效。
常见错误现象：
脚本开头写了 local PATH="/usr/local/bin"，结果发现 PATH 被覆盖、后续命令全挂了；或者函数里改了 local IFS，但退出后 IFS 没恢复，导致后续 for 循环解析出错。
-
local声明必须出现在变量首次赋值前（Bash 4.2+ 允许local var=value一行完成，但老版本不兼容） - 若函数内未用
local，同名变量会直接读写全局作用域，哪怕该变量尚未在全局定义过 - 函数参数（
$1,$2等）天然局部，无需、也不能用local再声明
local 变量屏蔽同名全局变量，退出后自动销毁
当函数内存在与全局同名的 local 变量时，函数体中所有对该变量的引用都指向局部副本，全局变量完全不可见——这不是“修改”，而是“遮蔽”。函数返回后，局部变量消失，全局变量原样保留。
使用场景：
需要临时修改环境变量（如 PATH、IFS、LC_ALL）执行一段逻辑，又不想影响后续流程；或封装工具函数时避免意外覆盖调用方已定义的变量名。
- 示例：
local PATH="/tmp/bin:$PATH"—— 仅在函数内生效，不影响父 shell 的PATH - 注意：数组也支持局部化，
local -a my_array=(1 2 3)，但local arr[0]=1这种写法无效，必须先声明再赋值 - 若需继承全局变量值再局部修改，得显式赋值：
local myvar="$myvar"（否则局部变量为空）
local 支持属性修饰，但 -r（只读）和 -i（整数）有陷阱
local 后可接 -r、-i、-a、-A 等修饰符，但行为和全局 declare 不完全一致。尤其 -r 在函数退出后不会“泄漏”只读属性到全局，这点很安全；但 -i 的整数校验仅在赋值时触发，不影响后续字符串操作。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
容易踩的坑：local -r uid=$(id -u) 是安全的；但 local -i count="abc" 会让 count 变成 0 且不报错，可能掩盖逻辑错误。
-
local -r声明后无法在函数内重新赋值，尝试uid=999会报错 -
local -i不阻止你后续用count="hello"赋值，只是让初始赋值时做类型转换 - 复合属性如
local -ri合法，但实际极少需要
调试 local 变量是否生效：用 declare -p 查看作用域
运行时判断变量是否真为局部，不能只靠眼力。在函数内加一句 declare -p varname，若输出含 local 字样（如 declare -l varname="value" 或 declare -- varname="value"），说明生效；若显示 declare -x 或无修饰，则仍是全局。
性能 / 兼容性影响：local 是 Bash/Zsh 内置，dash/sh 不支持。若脚本需 POSIX 兼容，应避免使用，改用子 shell (var=value; cmd) 隔离作用域。
- 检查当前 shell：
echo $0或ps -p $$，确保不是 dash - 函数内调试建议：
declare -p | grep "^local\|^varname"快速过滤 - 别依赖
set -o functrace查local，它只跟踪函数调用，不显示变量作用域
函数体内的 local 不是语法糖，它是 Bash 作用域隔离的唯一可靠手段。很多人以为“函数里定义就是局部”，结果在嵌套调用或同名变量多处出现时，才发现全局状态被悄悄改写——这种 bug 往往要花几小时才能定位。
