企业官网建设流程全解析

1. 从"OpenShell"这个名字说起：它到底指什么

第一次看到"OpenShell"这个词，很多人会下意识地把它和"开源终端""命令行外壳"联系起来。这个直觉不算错，但也不完整。在真实的工程语境里，OpenShell 至少承载着两层含义：一层是操作系统里那个负责接收用户输入、解释命令、启动程序的命令解释器（shell）；另一层，则是近几年在云原生、边缘计算、嵌入式设备管理领域频繁出现的一个开放外壳/开放运行时框架概念——它强调把底层能力"开放"出来，让上层应用、脚本、自动化流程能够以统一的方式接入。

我之所以要先把这层歧义讲清楚，是因为很多人搜"OpenShell"的时候，脑子里想的是 A，结果搜到的资料讲的是 B，越看越乱。所以这篇内容我打算把两条线都捋一遍，但重点放在工程实践中真正会用到的那部分：如何理解一个"开放外壳"的设计思路，如何在本地环境里把它跑起来，以及在实际落地时会踩哪些坑。

先给一个最朴素的定位：OpenShell 本质上是一个中间层。它向下对接操作系统或硬件资源，向上暴露一套相对稳定的接口。你可以把它想象成家里的"配电箱"——墙里的电线怎么走、电压稳不稳，你不需要每次都去管，你只需要知道哪个开关控制哪个回路。OpenShell 干的就是这个"配电箱"的活：把复杂、易变的底层细节封装起来，给上层一个干净、可预期的操作面。

这个定位决定了它的适用人群：如果你只是偶尔敲两条命令，那随便一个终端就够了；但如果你要管理几十上百台设备、要写自动化脚本、要让不同团队用同一套方式操作异构环境，那 OpenShell 这类东西的价值就出来了。它解决的核心问题不是"能不能执行命令"，而是"能不能用一致、可维护、可审计的方式执行命令"。

关键词里虽然只给了"OpenShell"这一个词，但围绕它的讨论通常离不开几个高频概念：命令解释器、交互式会话、脚本执行、环境变量、权限隔离、插件扩展。这几个词基本勾勒出了 OpenShell 的能力边界。下面我会逐个拆开讲，并且尽量给出可以直接上手操作的例子。

2. 命令解释器的工作机制：为什么它比你想的复杂

2.1 一条命令从敲下回车到执行完，中间发生了什么

很多人以为 shell 就是个"翻译器"，你输入什么它就执行什么。实际上，一条命令从你敲下回车到看到结果，中间至少经历了五个阶段，每个阶段都可能出问题。

第一个阶段是读取与分词（tokenization）。shell 拿到你输入的整行字符串后，首先要把它切成一个个"词"。这里有个容易被忽略的细节：分词不是简单按空格切。引号、转义符、变量替换都会影响切分结果。比如echo "hello world"和echo hello world看起来差不多，但前者是一个参数，后者是两个参数。这个区别在写脚本时经常导致 bug。

第二个阶段是展开（expansion）。分词之后，shell 会处理变量替换（$VAR）、命令替换（`cmd`或$(cmd)）、算术展开（$((1+2))）、路径展开（*.txt）等。这一步是 shell 最"魔法"也最容易出错的地方。我见过太多人写脚本时被路径展开坑到——明明想传一个字面量*，结果被展开成了一堆文件名。

第三个阶段是重定向与管道处理。>、>>、<、|这些符号决定了数据的流向。这里的关键点是：重定向的建立发生在命令执行之前，而且顺序很重要。cmd > file 2>&1和cmd 2>&1 > file的结果完全不同，前者把标准输出和标准错误都写进文件，后者只把标准输出写进文件、标准错误仍然打到终端。

第四个阶段是命令查找与执行。shell 会按照PATH环境变量里的顺序去找可执行文件。这里有个经典陷阱：如果你在当前目录下有个脚本叫test，而系统里也有个/usr/bin/test，那到底执行哪个取决于PATH里当前目录的位置。出于安全考虑，绝大多数现代 shell 默认不把当前目录放进PATH。

第五个阶段是退出码与信号处理。命令执行完会返回一个退出码，0 表示成功，非 0 表示失败。脚本里用$?可以拿到这个值。很多人写自动化脚本时不检查退出码，结果前一步失败了后面还在继续跑，最后出一堆莫名其妙的问题。

把这五个阶段理清楚，你对 OpenShell 这类工具的理解就会上一个台阶——因为它要做的，本质上就是把这五个阶段里"可配置、可扩展、可审计"的部分开放出来。

2.2 交互式会话与非交互式执行的区别

OpenShell 在实际使用中通常有两种模式：交互式会话和非交互式执行。这两者的行为差异比大多数人想象的要大。

交互式会话就是你在终端里一行一行敲命令。这种模式下，shell 会加载配置文件（比如.bashrc、.zshrc），会启用行编辑、历史记录、自动补全，会处理作业控制（Ctrl+Z、fg、bg）。这些功能让日常操作很舒服，但也意味着交互式会话的行为依赖于当前用户的个人配置。

非交互式执行则是脚本、定时任务、CI/CD 流水线里那种"跑完就退出"的模式。这种模式下，shell 通常不会加载交互式配置文件，环境变量可能完全不同，PATH可能更短，某些别名和函数根本不存在。这就是为什么"我本地跑得好好的脚本，放到服务器上就报 command not found"——不是脚本有问题，是执行环境不一样。

我个人的经验是：写任何要自动化执行的脚本时，第一行永远写清楚 shebang，并且在脚本开头显式设置好PATH和需要的环境变量。不要依赖"当前 shell 里刚好有"。比如：

#!/usr/bin/env bash set -euo pipefail export PATH="/usr/local/bin:/usr/bin:/bin:$PATH"

这里的set -euo pipefail是三个开关的组合：-e表示任何命令失败就退出，-u表示引用未定义变量就报错，-o pipefail表示管道中任何一环失败整个管道就算失败。这三条能帮你挡掉大量"静默失败"的坑。

2.3 环境变量与配置加载顺序

环境变量是 OpenShell 这类工具里最容易被低估的部分。它看起来简单——不就是键值对吗？但实际项目里，环境变量的问题能占到排错时间的一半以上。

配置加载顺序决定了最终生效的是哪个值。以常见的 bash 为例，登录 shell 会读/etc/profile、~/.bash_profile、~/.bash_login、~/.profile（按顺序找到第一个存在的就停），非登录交互式 shell 会读/etc/bash.bashrc、~/.bashrc。这个顺序意味着：后加载的会覆盖先加载的。

实操中我建议遵循一个原则：系统级配置放/etc，用户级配置放~，项目级配置放项目目录下的.env或专门的配置文件，并且项目级优先级最高。这样不同项目之间不会互相污染，换台机器也能快速复现。

提示：调试环境变量问题时，env命令列出当前所有环境变量，echo $VAR看单个变量，set还会包含 shell 函数和局部变量。三者用途不同，别混用。

3. 把 OpenShell 跑起来：环境准备与最小可用配置

3.1 选型：不同场景下该用哪种 shell

虽然都叫 shell，但不同实现之间的差异很大。选错了，后面写脚本会一直别扭。下面这张表是我根据实际项目经验整理的对比，供你参考。

选型逻辑其实很简单：要兼容性就选 POSIX，要功能就选 bash，要交互体验就选 zsh/fish，要跨 Windows 就选 PowerShell。最忌讳的是"我本地用 fish 写脚本，然后扔到只有 dash 的容器里跑"——语法根本不兼容。

如果你在做的是嵌入式或资源受限环境，dash 往往是更好的选择，因为它启动快、内存占用小。我实测过，在同样一个启动脚本上，dash 比 bash 快大约 30% 到 50%，在需要频繁启动子 shell 的场景下这个差距会累积得很明显。

3.2 最小可用配置：从零搭一个干净的 shell 环境

假设你现在拿到一台全新的机器，要把它配置成一个适合 OpenShell 类工具运行的环境。我的做法是分四步走，每一步都可验证。

第一步，确认基础 shell 和版本。不同版本的 bash 支持的特性不一样，比如关联数组是 bash 4.0 才有的，mapfile也是。跑一下：

bash --version | head -n 1 echo $SHELL

第二步，设置合理的PATH。不要无脑往PATH里塞一堆目录，目录越多，命令查找越慢，而且越容易撞名。我的习惯是只保留必要的几个，并且把自定义脚本目录放在最后：

export PATH="/usr/local/bin:/usr/bin:/bin:$HOME/.local/bin"

第三步，配置历史记录和补全。历史记录不只是方便，它还是排错的重要线索。我一般会设置历史记录带时间戳、去重、并且不限条数：

export HISTTIMEFORMAT="%F %T " export HISTCONTROL=ignoreboth export HISTSIZE=100000 export HISTFILESIZE=200000

第四步，加一层安全网。在.bashrc里加上set -o vi或者set -o emacs取决于你的习惯，但更重要的是加上命令别名来防止误操作：

alias rm='rm -i' alias cp='cp -i' alias mv='mv -i'

这几个-i会在覆盖或删除前问你一句。有人觉得烦，但我在生产环境里见过太多次"手一抖删错文件"的事故，这几个交互确认能救命。

3.3 验证配置是否生效的检查清单

配置写完不代表生效。我习惯用下面这个清单逐项验证，避免"以为配好了其实没生效"。

• 新开一个终端，echo $PATH看顺序对不对。
• type -a ls看命令解析到了哪个路径。
• history 10看历史记录格式和时间戳。
• alias看别名是否加载。
• 跑一个带set -euo pipefail的小脚本，故意让它失败，确认退出码非 0。

这套检查下来，基本能覆盖 90% 的配置问题。剩下的 10% 通常是配置文件之间的加载顺序冲突，需要看~/.bash_profile里有没有正确 source~/.bashrc。

4. 脚本化与自动化：把重复劳动交给 OpenShell

4.1 从"能跑"到"可靠"：脚本健壮性的四个层次

写脚本这件事，新手和老手的差距不在于"会不会写"，而在于"写得靠不靠谱"。我把脚本的健壮性分成四个层次，你可以对照看看自己在哪一层。

第一层：能跑通。脚本在你自己机器上、用你自己的账号、按你预期的顺序执行，能出结果。这是最低要求，但很多脚本就停在这一层。

第二层：能报错。脚本遇到问题时不会静默失败，而是明确告诉你哪里错了。这需要set -e、检查退出码、输出有意义的错误信息。

第三层：能重跑。脚本执行到一半失败了，重新跑一遍不会产生重复数据或副作用。这需要幂等设计，比如创建目录前先判断是否存在，写文件前先检查内容。

第四层：能审计。脚本每一步做了什么、花了多久、影响了哪些资源，都有日志可查。这在生产环境里是刚需。

我见过太多"第一层脚本"被直接扔进定时任务，然后某天因为一个网络抖动就产生了脏数据。所以我的建议是：任何要重复执行的脚本，至少要做到第三层。

4.2 参数解析与用户输入处理

脚本要通用，就得能接受参数。参数解析看起来简单，但细节很多。下面是一个我常用的模板，支持短选项、长选项和位置参数：

#!/usr/bin/env bash set -euo pipefail usage() { echo "用法: $0 [-v] [-o output] input_file" exit 1 } verbose=false output="" while getopts "vo:h" opt; do case $opt in v) verbose=true ;; o) output="$OPTARG" ;; h) usage ;; *) usage ;; esac done shift $((OPTIND - 1)) input="${1:-}" if [[ -z "$input" ]]; then echo "错误: 缺少输入文件" >&2 usage fi

这里有几个关键点值得说明。getopts是 POSIX 标准，兼容性最好；OPTARG是当前选项的参数值；OPTIND是下一个待处理参数的索引，shift $((OPTIND - 1))用来跳过已处理的选项，剩下的就是位置参数。${1:-}的写法是为了在set -u下安全地取可能不存在的参数。

注意：getopts不支持长选项（如--output）。如果需要长选项，得用getopt（注意不是getopts）或者手动解析。手动解析虽然啰嗦，但可控性最强，我在复杂脚本里更倾向手动解析。

4.3 错误处理与日志：让脚本自己说清楚发生了什么

日志这件事，我的原则是：日志要能回答"什么时候、在哪台机器、哪个用户、执行了什么、结果如何"。缺了任何一项，排错时都会抓瞎。

一个实用的日志函数长这样：

log() { local level="$1"; shift printf '[%s] [%s] [%s] %s\n' \ "$(date '+%Y-%m-%d %H:%M:%S')" \ "$level" \ "${HOSTNAME:-unknown}" \ "$*" } log INFO "开始处理文件: $input" log ERROR "文件不存在: $input"

配合trap可以捕获脚本退出和信号，做清理工作：

cleanup() { local exit_code=$? log INFO "脚本退出，退出码: $exit_code" rm -f "$tmp_file" 2>/dev/null || true exit "$exit_code" } trap cleanup EXIT INT TERM

trap ... EXIT保证无论脚本是正常结束还是中途出错，清理逻辑都会执行。这一点在创建了临时文件、打开了网络连接、加了锁的场景下特别重要。我踩过的坑是：脚本中途被Ctrl+C中断，临时文件留在磁盘上，下次跑的时候因为文件已存在而报错。加了trap之后这类问题基本绝迹。

4.4 并发与批量操作：别让脚本一条道走到黑

当你要处理成百上千个文件或设备时，串行执行会慢到让人崩溃。这时候需要并发。但并发不是简单加个&就完事，控制不好会打爆系统资源。

我的做法是用一个简单的并发控制模式：

max_jobs=8 job_count=0 for item in "${items[@]}"; do process "$item" & ((job_count++)) if (( job_count >= max_jobs )); then wait -n ((job_count--)) fi done wait

wait -n会等待任意一个后台任务结束，这样就能保持同时运行的任务数不超过max_jobs。这个模式比"一次性全放出去再 wait"要稳得多，尤其在任务本身消耗内存或网络带宽的时候。

实测下来，8 到 16 的并发度在大多数场景下是甜点区。再高，收益递减，而且容易触发对端限流。具体数值还是要根据任务类型调，IO 密集型的可以高一些，CPU 密集型的建议不超过核数。

5. 权限、隔离与安全边界：OpenShell 最容易被忽视的一面

5.1 最小权限原则在 shell 环境里的落地

"最小权限"这个词大家都听过，但真正在 shell 环境里做到位的不多。最常见的反例就是：为了图省事，直接用 root 跑所有脚本。这等于把整个系统的钥匙交给了一个可能写错的脚本。

我的做法是按职责分账号。比如：部署脚本用一个只有部署目录写权限的账号，日志收集用一个只能读日志目录的账号，定时清理用一个只能删特定目录的账号。这样即使某个脚本被写错或被恶意利用，影响范围也被限制住了。

具体操作上，sudo的配置是关键。不要给ALL=(ALL) NOPASSWD: ALL这种万能授权，而是精确到命令：

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp

这样deploy账号只能重启myapp这一个服务，别的什么都干不了。粒度是粗了点，但比全放开安全太多。

5.2 输入校验：别相信任何外部传入的数据

脚本的输入可能来自用户、来自文件、来自网络。这些数据都不能直接信任。最典型的风险是命令注入：如果脚本里写了eval "$user_input"或者sh -c "$user_input"，那用户输入; rm -rf /就完蛋了。

正确的做法是：能不用eval就不用，必须拼接命令时用数组而不是字符串。

# 危险写法 cmd="ls $dir" eval "$cmd" # 安全写法 ls -- "$dir"

数组的写法更安全，因为每个元素是独立的参数，不会被再次分词：

args=("--target" "$target" "--output" "$output") some_command "${args[@]}"

另外，对文件路径要做规范化处理，防止../穿越。可以用realpath拿到绝对路径，再检查是否在允许的目录范围内。

5.3 敏感信息的处理：密码、密钥、令牌

脚本里最不该出现的就是明文密码。但现实中，"把密码写在脚本里"这种事太常见了。我理解图方便的心理，但代价太大——脚本一旦泄露，密码就泄露了。

替代方案有几个层次。最简单的是用环境变量传入，脚本里只引用不硬编码：

db_password="${DB_PASSWORD:?必须设置 DB_PASSWORD 环境变量}"

${VAR:?message}的写法在变量未设置时会报错退出，避免用空密码去连接。

更进一步，可以用专门的密钥管理服务，脚本运行时动态获取。再进一步，可以用短期凭证代替长期密码。具体用哪种取决于你的环境成熟度，但至少要做到不硬编码。

提示：即使不硬编码，也要注意别把敏感信息打到日志里。set -x调试时会把所有展开后的命令打出来，包括密码。调试完记得关掉，或者用set +x在敏感操作前后临时关闭。

5.4 审计与追溯：出了问题能查到是谁干的

审计的价值在出问题时才体现出来。平时觉得"记日志麻烦"，真出了事故，没有日志就只能靠猜。

我在生产脚本里会记录这几类信息：执行者身份、执行时间、执行的完整命令、影响的目标、执行结果。这些信息汇总到一个集中的日志系统里，出问题时按时间线一拉，整个操作链路就清楚了。

实现上，可以在脚本入口处统一记录：

audit_log() { printf '%s|%s|%s|%s\n' \ "$(date -Iseconds)" \ "${USER:-unknown}" \ "${SSH_CONNECTION:-local}" \ "$*" >> /var/log/openshell-audit.log } audit_log "执行部署: target=$target version=$version"

这个日志文件要设置好权限，只允许追加不允许修改，防止被篡改。

6. 扩展与集成：让 OpenShell 融入现有工作流

6.1 插件机制与自定义命令

一个成熟的 OpenShell 环境，通常支持通过插件或自定义命令来扩展能力。核心思路是：把可执行文件放到PATH里的某个目录，shell 就能像调用内置命令一样调用它。

比如你想加一个deploy命令，只要写一个可执行脚本放到~/.local/bin/deploy，然后确保~/.local/bin在PATH里，就能直接敲deploy了。这个机制简单但极其强大，是 shell 生态灵活性的根源。

写自定义命令时有几个约定值得遵守：退出码要有意义（0 成功，非 0 失败且不同值代表不同错误）、输出要区分 stdout 和 stderr（正常结果走 stdout，错误和提示走 stderr）、支持-h显示帮助。这些约定让自定义命令能和系统命令无缝配合。

6.2 与 CI/CD 流水线的对接

在 CI/CD 环境里跑 shell 脚本，和本地跑有几个关键差异。第一，环境是干净的，没有你本地那些别名和函数。第二，没有交互，任何需要输入的地方都会卡住。第三，超时限制，跑太久会被强制终止。

针对这三点，我的应对是：脚本里所有交互都改成参数或环境变量驱动；所有可能卡住的操作加超时（timeout 30 some_command）；长任务拆成小步骤并输出进度，方便判断卡在哪一步。

还有一个细节：CI 环境里的TERM变量可能没设置，导致某些命令输出乱码或行为异常。可以在脚本开头设export TERM=dumb，让输出变成纯文本。

6.3 跨平台兼容的注意事项

如果你的脚本要在 Linux 和 macOS 上都跑，有几个坑必须提前知道。第一，sed和awk的实现在两个平台上不完全一样，某些 GNU 扩展在 macOS 的 BSD 版本上不支持。第二，date命令的参数格式不同，macOS 用-v而 Linux 用-d。第三，readlink -f在 macOS 上默认不可用。

应对策略是：尽量用 POSIX 标准语法，避免平台特有扩展。实在避不开的，用条件判断区分处理：

if [[ "$(uname)" == "Darwin" ]]; then # macOS 特有逻辑 else # Linux 逻辑 fi

或者干脆用容器把环境统一起来，这是最省心的方案。我在跨平台项目里越来越倾向于用容器，因为"一次编写到处运行"的承诺，只有环境一致时才成立。

7. 排错实战：几个我真实踩过的坑

7.1 "command not found" 的三种不同原因

这个报错太常见了，但原因可能完全不同。第一种是命令真的不存在，需要安装。第二种是命令存在但不在PATH里，需要加路径或改PATH。第三种最隐蔽：命令存在、PATH也对，但当前用户没有执行权限。

区分方法很简单：which cmd看能不能找到，ls -l $(which cmd)看权限位，echo $PATH看路径。三步下来基本能定位。我遇到过最坑的一次是：脚本在交互式 shell 里跑没问题，放到 cron 里就 command not found。原因是 cron 的PATH极短，只有/usr/bin:/bin。解决办法是在 crontab 里显式设置PATH，或者脚本里用绝对路径。

7.2 引号与转义：90% 的脚本 bug 来源

引号问题我单独拎出来讲，因为它太容易错了。核心规则就三条：双引号里的变量会展开，单引号里的不会，不加引号的变量会分词和路径展开。

name="hello world" echo $name # 输出: hello world（但被当成两个参数） echo "$name" # 输出: hello world（一个参数） echo '$name' # 输出: $name（字面量）

最安全的写法是：变量引用永远加双引号，除非你明确知道需要分词。"$var"这个习惯能帮你避免大量问题。我见过因为少写一对引号导致文件名带空格时脚本崩溃的案例，排查了半天才发现是引号问题。

7.3 管道与子 shell 的变量作用域陷阱

这个坑很隐蔽：管道里的每一段都在子 shell 里执行，子 shell 里修改的变量不会影响父 shell。

count=0 echo "a b c" | while read -r word; do ((count++)) done echo "$count" # 输出 0，不是 3

解决办法是用进程替换或者重定向代替管道：

count=0 while read -r word; do ((count++)) done < <(echo "a b c") echo "$count" # 输出 3

< <(...)是进程替换，它把命令的输出变成一个临时文件描述符，while 循环在当前 shell 里执行，变量就能正常累加了。这个技巧在处理需要计数的循环时特别有用。

7.4 信号处理与优雅退出

脚本被kill的时候，默认行为是立即终止，可能留下半成品状态。要优雅退出，就得捕获信号。

trap 'echo "收到中断信号，正在清理..."; cleanup; exit 130' INT TERM

退出码 130 是128 + 2，2 是SIGINT的信号编号。用这个约定能让调用方知道脚本是被中断的，而不是正常失败。这个细节在自动化流水线里很重要，因为有些系统会根据退出码决定是否重试。

8. 性能调优：让脚本跑得更快一点

8.1 减少子进程创建

shell 脚本慢，很多时候慢在频繁创建子进程上。每次用反引号或$()做命令替换，每次用管道，都会 fork 一个新进程。在循环里做这些操作，开销会累积。

优化方法是用 shell 内置功能代替外部命令。比如字符串长度用${#var}而不是echo "$var" | wc -c，字符串替换用${var//old/new}而不是echo "$var" | sed 's/old/new/g'。这些内置操作不创建子进程，速度快一个数量级。

我实测过一个处理十万行文本的脚本，把循环里的sed换成内置替换后，耗时从 40 多秒降到 3 秒以内。差距就是这么夸张。

8.2 批量处理代替逐条处理

另一个常见问题是"逐条处理"。比如要删除一千个文件，写个循环一个个rm，那就要 fork 一千次。改成rm file1 file2 ... file1000一次调用，快得多。

同理，grep能一次处理多个文件就不要循环调用，awk能一次算完的就不要拆成多步。让每个外部命令处理尽可能多的数据，减少调用次数，这是 shell 性能优化的核心思路。

8.3 什么时候该换语言

shell 不是万能的。当脚本逻辑复杂到需要嵌套数据结构、需要复杂字符串处理、需要并发控制的时候，继续用 shell 写只会越来越痛苦。这时候该考虑换 Python、Go 之类的语言。

我的判断标准是：如果脚本超过 300 行，或者需要处理 JSON/XML 这类结构化数据，或者需要维护复杂状态，就该换语言了。shell 的定位是"胶水"，把各个工具粘起来，而不是做重型逻辑。认清这个边界，能省下大量维护成本。

9. 我个人的几条实操心得

关于 OpenShell 这类工具，我用了这么多年，有几条体会是文档里不会写、但实际工作中特别有用的。

第一条，配置文件要进版本控制。你的.bashrc、.zshrc、自定义脚本，都应该放在 Git 仓库里。换机器时 clone 下来就能用，改坏了也能回滚。我见过太多人配置丢了之后凭记忆重写，结果漏了一堆细节。

第二条，给脚本写测试。shell 脚本也能测试，用bats这类框架，或者简单点用断言函数。关键逻辑有测试覆盖，改起来才敢改。没有测试的脚本，改一行都心惊胆战。

第三条，日志级别要分明。DEBUG、INFO、WARN、ERROR 分清楚，平时只输出 INFO 以上，排错时开 DEBUG。全量输出 DEBUG 日志的脚本，跑起来又慢又吵，真出问题时反而找不到重点。

第四条，别追求一次写完美。脚本是演进的，先写能跑的版本，遇到问题再加固。我见过有人为了"一开始就设计完美"而迟迟不动手，结果需求变了，设计全白费。小步快跑，持续重构，才是正道。

第五条，文档写在脚本里。脚本开头的注释块写清楚用途、参数、依赖、示例，比单独写个 README 更不容易过时。因为改脚本的人一定会看到注释，但不一定会去看 README。

这些心得没有一条是技术难点，但每一条都能实实在在减少你踩坑的次数。工具是死的，用法是活的，把 OpenShell 这类东西真正用顺手，靠的不是记住多少命令，而是建立起一套适合自己的工作习惯。