shell函数内修改全局变量失效，因默认赋值仅限函数局部作用域；需避免local声明、子shell（如|、$()）及确保未启用隔离环境。
shell 函数里改全局变量为什么没生效
因为默认情况下，bash 函数内对变量的赋值只在子 shell 或局部作用域生效，除非显式声明为全局或使用 export（仅对环境变量有效）。常见现象是：函数里写了 count=5，调用完后 echo $count 还是空或旧值。
- 普通变量在函数内直接赋值，作用域仅限该函数——除非该函数未启用子 shell（比如没用管道、命令替换等），且变量未被
local声明 - 想修改外层变量，最稳妥的方式是**不声明
local，也不用子 shell 语法（如$(...)或|）包裹函数调用** - 如果用了
local var=value，那这个var就彻底隔离了，外部永远看不到 -
export只影响子进程可见性，不能让父 shell “回写”变量值
local 声明后变量到底在哪能访问
local 是 bash/zsh 特性（POSIX sh 不支持），它让变量只在当前函数及嵌套调用的函数中可见，退出函数即销毁。不是“局部作用域”那么简单——它还压制同名全局变量的读取。
- 函数 A 中
local x=1，再调用函数 B，B 里没声明x，则echo $x输出空（不是继承 A 的值） - 但如果 B 里也写
local x，那它是全新变量，和 A 的x无关 - 在函数内用
echo ${x:-default}时，若x是local且未赋值，不会 fallback 到全局x，而是真为空 - zsh 行为基本一致，但 dash/sh 下遇到
local会直接报错：command not found
子 shell 场景下变量传递的真相
只要出现 (...)、$(...)、|，就可能触发子 shell，此时父 shell 的变量修改完全无法穿透回去——这不是作用域问题，是进程隔离。
Shell脚本编写基础 中文WORD版
下载
Shell本身是一个用C语言编写的程序，它是用户使用Linux的桥梁。Shell既是一种命令语言，又是一种程序设计语言。作为命令语言，它交互式地解释和执行用户输入的命令；作为程序设计语言，它定义了各种变量和参数，并提供了许多在高级语言中才具有的控制结构，包括循环和分支。它虽然不是Linux系统核心的一部分，但它调用了系统核心的大部分功能来执行程序、建立文件并以并行的方式协调各个程序的运行。因此，对于用户来说，shell是最重要的实用程序，深入了解和熟练掌握shell的特性极其使用方法，是用好Linux系统
-
myfunc() { count=10; }; myfunc | cat→count在子 shell 里改，主 shell 仍无变化 -
result=$(myfunc)中，即使myfunc内部改了count，返回后主 shell 的count还是原样 - 绕过方法只有两个：用命令替换捕获输出（
count=$(myfunc)），或把逻辑写成不依赖子 shell 的形式（比如用{ ...; }替代(...)） - 注意：
for i in $(seq 3); do ...; done中的循环体不是子 shell，但$(seq 3)本身是——变量修改只在循环体内有效
跨脚本 source 时的变量污染风险
source 或 . 是把另一个文件内容“粘贴”进当前 shell 执行，所以它的变量声明、函数定义、local 行为全部按当前作用域规则走——容易误以为“隔离”，其实完全不隔离。
- 被
source的脚本里写了PATH=/tmp/bin:$PATH，当前 shell 的PATH真的就被改了 - 如果它定义了
local helper() { ... }，而你当前 shell 已有同名函数，source后那个helper就覆盖了原来的 - 没有“模块化”机制，想避免污染只能靠命名约定（如加前缀
mylib_init）或手动清理（unset不必要的变量/函数） - 检查是否被污染？执行
set | grep -E '^(varname|funcname)='，看输出来源是否符合预期
真正麻烦的从来不是“怎么声明”，而是“哪次调用悄悄启了子 shell”或者“哪个 source 文件在末尾偷偷重置了 IFS”。多用 set -x 跟一次变量生命周期，比背规则管用。
