默认情况下shell函数内无法修改全局变量，因赋值仅在函数作用域生效；若函数未在子shell（如管道右侧、$(...)、&）中运行，则可直接修改全局变量；需跨作用域写入时可用bash 4.2+的declare -g或避免子shell。
shell 函数里改不了全局变量？
默认情况下，函数内部对变量的赋值只在函数作用域生效，函数退出后就丢了。这不是 bug，是 POSIX shell 的设计行为——除非你显式声明或避开子 shell 陷阱。
常见错误现象：myvar="old"; myfunc() { myvar="new"; }; myfunc; echo $myvar 输出还是 old，尤其容易在管道后调用函数时误以为能改外层变量。
- 如果函数没被管道、
$(...)或后台执行（&），它和父 shell 共享同一进程，此时直接赋值就能改全局变量 - 但只要函数出现在管道右侧（如
echo x | myfunc），它就在子 shell 中运行，任何变量修改都无效 - 想强制跨作用域写入，用
export -g（bash 4.2+）或避免子 shell：把管道逻辑移到函数内，或用重定向替代管道
local 变量到底藏在哪？
local 是 bash/zsh 特性，不是 POSIX 标准。它让变量只在当前函数及其子函数中可见，退出即销毁。但要注意：同名 local 会屏蔽外层同名变量，且不会继承初始值。
使用场景：写可复用函数时防止污染全局命名空间，比如循环计数器、临时路径拼接。
-
local必须在函数第一行之后、首次使用前声明；写成local x=$(cmd)是安全的，但local x; x=$(cmd)才真正隔离作用域 - zsh 默认启用
LOCAL_OPTIONS，bash 需要显式local，dash/sh 等 POSIX shell 完全不支持，直接报错 - 性能影响极小，但滥用
local声明大量变量可能略微拖慢函数启动（解析开销）
为什么 export 后变量还是找不到？
export 让变量传给子进程，但对当前 shell 的变量作用域没影响。很多人以为 export foo=bar 就能让后续函数“看到”它，其实只是确保 bash -c 'echo $foo' 这类子进程能读到。
Shell本身是一个用C语言编写的程序，它是用户使用Linux的桥梁。Shell既是一种命令语言，又是一种程序设计语言。作为命令语言，它交互式地解释和执行用户输入的命令；作为程序设计语言，它定义了各种变量和参数，并提供了许多在高级语言中才具有的控制结构，包括循环和分支。它虽然不是Linux系统核心的一部分，但它调用了系统核心的大部分功能来执行程序、建立文件并以并行的方式协调各个程序的运行。因此，对于用户来说，shell是最重要的实用程序，深入了解和熟练掌握shell的特性极其使用方法，是用好Linux系统
典型错误：export PATH="/my/bin:$PATH"; myfunc() { echo $PATH; } —— 这没问题；但若 myfunc() { export PATH="/other:$PATH"; }，函数退出后 $PATH 依然不变，因为 export 不改变当前 shell 的变量值，只设置导出标记。
- 导出变量不能解决函数内修改全局变量的问题，它解决的是“子进程能否继承”的问题
- 导出大变量（如含长字符串的
PS1）可能轻微增加 fork 开销，但通常可忽略 - 检查是否导出：用
declare -p | grep -E "^[a-z]+="看哪些变量带-x标记
bash 和 dash/zsh 在作用域上有什么实际差异？
写跨 shell 兼容脚本时，最大的坑是 local 和子 shell 行为。dash（/bin/sh 默认）不支持 local，bash 4.2+ 支持 declare -g，zsh 则允许 typeset 和更灵活的作用域控制。
兼容性建议：如果脚本开头是 #!/bin/sh，就别用 local；如果明确用 #!/bin/bash，可用 declare -g 强制写全局变量，比反复 export 更准确。
- bash 中
declare -g var=value能从任意嵌套层级写最外层变量，但 zsh 不认这个语法，得用typeset -g - dash 下函数无法访问父 shell 的未导出变量（即使没管道），而 bash/zsh 可以——这是 POSIX 合规性取舍
- 测试兼容性：用
sh -n script.sh检查语法错误，再用dash script.sh实际跑一遍关键路径
作用域问题很少单独爆发，大多藏在管道、子 shell、跨 shell 移植或嵌套函数调用里。盯住进程层级（ps -o pid,ppid,comm），比死记规则更管用。
