shell变量赋值等号两边不能有空格，否则被解析为命令执行；含特殊字符的值需加引号；引用推荐${var}避免歧义；子进程需export才能继承变量；命令替换用$(...)更安全清晰。
Shell变量用错一个空格就报 command not found，不是语法太难，而是几个关键点卡死人。
变量赋值时等号两边为什么不能有空格
因为 shell 会把 VAR = value 当成执行命令 VAR，传参 = 和 value，自然找不到这个命令。正确写法只有 VAR=value —— 中间零空格。
- 错误示例：
PATH = /usr/bin:/bin→ 报错bash: PATH: command not found - 正确写法：
PATH=/usr/bin:/bin或更安全的PATH="${PATH}:/my/bin" - 如果值含空格、
*、$、反引号等，必须加引号：msg="hello world"，否则msg=hello world实际只赋了hello，world被当新命令执行
引用变量时为什么推荐用 ${VAR} 而不是 $VAR
因为 $VARname 会被解释为变量 VARname，而不是 VAR 后拼字符串 name。花括号明确界定变量边界，避免歧义。
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 假设
dir=/tmp，想拼路径/tmp/log：写"$dir/log"会出错（实际展开成/tmp/log但变量名被误读），必须写"${dir}/log" - 在字符串中混用多个变量也依赖花括号：
"${user}_${host}.conf"，否则$user_$host.conf会被当成变量user_和host.conf - 即使单个变量，养成
${VAR}习惯能减少后续扩展时的修 bug 成本
子进程看不到变量？export 不是可选项
普通变量只在当前 shell 进程有效；子进程（比如你执行的 git、ls、或另一个 sh 脚本）默认完全看不见它。要让子进程继承，必须 export。
- 先赋值再导出：
MY_DIR="/opt/app"; export MY_DIR - 一步到位：
export MY_DIR="/opt/app" - 验证是否生效：
env | grep MY_DIR（set会显示所有变量，包括未导出的） - 常见陷阱：在脚本里
export VAR=value，但该脚本是source执行的——这时变量留在当前 shell；如果是./script.sh执行，则子 shell 导出后退出即失效，父 shell 仍看不到
变量值里有命令结果？用 $(...) 而不是反引号
$(...) 是现代写法，嵌套清晰、可读性高；反引号 `...` 嵌套需层层转义，极易出错。
- 获取文件行数：
count=$(wc -l ，不是 <code>count=`wc -l - 嵌套命令：
base=$(basename $(dirname "$path"))，用反引号就得写成base=`basename \`dirname "$path"\``，多一层就多一个漏转义的风险 - 注意：命令替换结果自动去除首尾换行符，但保留中间空格；如需保留全部空白，得用双引号包裹：
output="$(cat file)"
真正容易被忽略的，是变量作用域和导出时机的组合问题——比如在循环里反复 export VAR=xxx 看似没问题，但若循环体中又调用了子 shell，而你没确认该子 shell 是否真从父进程继承了这个变量，就可能在某次部署时静默失败。
