如果你经常在终端里和多个项目打交道八成经历过这种场景刚在 A 项目里 export 了一堆环境变量切到 B 项目继续敲命令结果API_BASE还指着 A 的地址日志级别也是 A 的调法提示符更是一点提示都没有。我以前也觉得这不是什么大事直到有一回因为PROJECT_ROOT残留一条清理脚本删错了目录才意识到问题有多严重。后来我写了个小工具名字就叫 context-mode核心就一句话把 shell 当前的工作状态当成一个可以显式切换的“模式”来管理。这篇文章会把它是怎么来的、解决了什么问题、完整脚本和后来踩过的坑都讲清楚适合所有经常在终端里切换环境、或者想给脚本加一套状态管理的开发者。1. 一次环境残留事故让我决定把 context-mode 做成工具1.1 事故现场还原当时我同时维护两个本地项目一个叫 web-demo另一个叫 cli-tool。web-demo 里有个环境变量PROJECT_ROOT/opt/web-democli-tool 里的构建脚本会读取同一个变量然后执行rm -rf $PROJECT_ROOT/backup来清理临时备份目录。我那天先跑完 web-demo 的命令接着直接 cd 到 cli-tool 目录跑构建脚本里的PROJECT_ROOT还是 web-demo 的值结果把 web-demo 的 backup 目录整个删了。好在是测试数据不然真的不好交代。排查过程并不复杂。我先env | grep PROJECT看到变量值仍然指向 web-demo又echo $LOG_LEVEL发现日志级别也是 web-demo 设置过的 DEBUG。问题很清楚在 shell 里环境变量是全局状态cd 切换目录不会自动更新它们。任何脚本只要依赖环境变量就可能在使用者切了目录之后用到旧上下文的值。我当时的第一个想法是写一堆unset命令手工清理但项目一多根本管不住于是才动了做一个切换工具的念头。1.2 问题本质是 shell 缺少上下文感知再往深想一步这个问题的本质是shell 本身没有“当前工作在哪个项目/哪个环境”的概念。目录只是目录变量只是变量两者之间没有任何绑定关系。正常的开发者在脑子里的上下文是“我现在在 web-demo要用测试环境”但 shell 不知道它只会忠实保留上一次 export 的值。我需要的其实是一套显式的上下文机制一个当前模式标记、一组与环境绑定的变量、一个切换动作。切换时把旧模式的变量全部清掉再加载新模式的值。这样就不会出现两个项目变量混合的情况。与此同时这个模式标记应该常驻在提示符里让我一眼就知道自己在哪个状态。我顺手就管这套东西叫 context-mode——上下文模式。后来我发现这个思路在软件领域到处都是。编辑器有上下文感知的展示日志系统有上下文追踪版本管理工具也有上下文行数的概念。它们做的事都差不多先知道自己在哪再决定展示什么、怎么处理。2. 别以为 context-mode 只在终端里高频场景的统一密码2.1 编辑器里的上下文模式很多人写代码时都遇到过一种迷失感光标在文件中间滚动看半天想不起来自己到底在哪个函数里。编辑器插件解决这个问题的方式就是 context-mode 的一种体现——在可视窗口上方固定显示当前函数名、类名甚至 if/else 块结构。我用的编辑器插件会把当前函数签名钉在顶部滚动代码时始终可见。这个模式解决的不是变量污染而是信息裁剪屏幕空间有限编辑器主动判断“你正在哪个上下文中”把最关键的那一行上下文信息顶到显眼位置其余内容照常滚动。它把一个从上下文里推理出来的结论实时展示给你避免你反复上下翻页确认位置。2.2 版本控制里的上下文行数再看版本控制工具。git diff默认不是只显示改动的行而是会显示改动前后的若干行这几行就叫上下文行作用是把改动“嵌在”原始逻辑里。你可以通过-U行数控制上下文范围比如git diff -U5表示显示改动行前后各 5 行。为什么要有这个设计因为一份 diff 如果没有上下文就只是一堆孤立的增删记录无法判断改动到底发生在哪个条件分支里上下文太多了又会被无关代码淹没。你选择-U3还是-U20其实就是现场切换 diff 的 context-mode。这个选择和终端里的模式切换一样都是在调整“上下文信息的可见度”。2.3 日志系统里的上下文追踪稍微复杂一点的日志框架都有 MDCMapped Diagnostic Context或者类似的结构化字段机制。它把请求 ID、用户 ID、会话 ID 这类信息塞进一条日志里让所有相关日志能串起来。这个模式在排查问题的时候尤其好用。我调试过一个支付回调问题订单号就是日志上下文里的固定字段。所有日志都能按订单号过滤问题链路一眼就能理清。相比之下如果每条日志只输出自己的 message没有携带“我属于哪个请求”的上下文出了问题就只能靠时间戳大海捞针。这里的 context-mode 是“附加哪些上下文信息”而不是“切换哪组变量”但底层思想完全一致先明确自己在哪个状态里再决定输出什么。2.4 权限与运行模式的切换很多程序支持多种运行模式比如普通模式、调试模式、只读模式它们本质上也是一种 context-mode。同一个程序根据当前模式限制某些操作或者开放更多输出。走查配置时经常看到类似--context-modedebug或--profileproduction的参数本质就是让程序在一组预定义的上下文里做选择。这类设计有个共同点模式是显式的不是靠猜的。你不能让程序“自动推断”自己该不该进入调试模式而是通过环境变量、命令行参数或配置显式告诉它。这样出现问题的时候别人能直接看到当前模式是什么而不是反复检查代码入口。我自己的 context-mode 工具也沿用了这个思路用一个CONTEXT_MODE_NAME变量存储当前模式任何子进程都能拿到。场景context-mode 的体现解决的核心问题编辑器顶部固定显示当前函数/类信息裁剪与定位版本控制diff 上下文行数理解改动背景日志系统请求 ID 等字段追加链路追踪运行模式debug/release/readonly行为隔离3. 直接可用手写一个 context-mode 切换器3.1 总体设计配置文件加函数加提示符我给自己定了几条规则。第一每个上下文是一个配置文件对dev.env存环境变量dev.alias存别名第二切换动作是一个函数必须在当前 shell 进程里执行否则改不了环境变量第三把当前上下文写进一个 state 文件这样开新终端时还能恢复第四提示符要显示出当前模式不然模式再清晰也容易忘。目录结构非常简单~/.context-mode/ dev.env dev.alias test.env test.alias statedev.env内容例如export PROJECT_ENVdev export LOG_LEVELDEBUG export API_BASEhttp://127.0.0.1:8000test.env内容例如export PROJECT_ENVtest export LOG_LEVELINFO export API_BASEhttp://test.example.comdev.alias内容例如alias dcdocker compose alias cm_statuscm status注意 alias 里我故意放了一个cm_status其实函数名和 alias 重名会绕实际使用不建议这么写这里只是演示配置文件会被 source 进来。生产版本建议给函数统一加前缀比如__cm开头alias 只留用户友好的短命令避免递归调用。3.2 脚本主体与安装步骤下面是我精简过的完整脚本保存为~/.context-mode.sh然后在~/.bashrc里加一行source ~/.context-mode.sh即可。#!/usr/bin/env bash # context-mode: 一个极简的 shell 上下文模式管理工具 # 用法: # cm list 列出所有可用上下文 # cm use name 切换到指定上下文 # cm clear 清除当前上下文 # cm status 显示当前上下文 CONTEXT_MODE_HOME${CONTEXT_MODE_HOME:-$HOME/.context-mode} CONTEXT_MODE_STATE${CONTEXT_MODE_HOME}/state __cm_set_prompt() { local current if [[ -f ${CONTEXT_MODE_STATE} ]]; then current$(cat ${CONTEXT_MODE_STATE} 2/dev/null) fi local ctx if [[ -n ${current} ]]; then ctx[${current}] fi export PS1\\[\\e[1;32m\\]\\u\\h\\[\\e[0m\\]:\\[\\e[1;34m\\]\\w\\[\\e[0m\\] ${ctx}\$ } __cm_clear() { local old_ctx [[ -f ${CONTEXT_MODE_STATE} ]] old_ctx$(cat ${CONTEXT_MODE_STATE}) if [[ -n ${old_ctx} -f ${CONTEXT_MODE_HOME}/${old_ctx}.env ]]; then while IFS read -r key _; do key${key#export } key${key%%*} key$(echo ${key} | tr -d ) if [[ ${key} ~ ^[A-Za-z_][A-Za-z0-9_]*$ ]]; then unset ${key} 2/dev/null || true fi done ${CONTEXT_MODE_HOME}/${old_ctx}.env fi : ${CONTEXT_MODE_STATE} export CONTEXT_MODE_NAME __cm_set_prompt } __cm_use() { local name$1 local env_file${CONTEXT_MODE_HOME}/${name}.env if [[ ! -f ${env_file} ]]; then echo context-mode: 找不到上下文 ${name} 的配置文件 ${env_file} 2 return 1 fi __cm_clear set -a source ${env_file} set a local alias_file${CONTEXT_MODE_HOME}/${name}.alias if [[ -f ${alias_file} ]]; then source ${alias_file} fi echo ${name} ${CONTEXT_MODE_STATE} export CONTEXT_MODE_NAME${name} __cm_set_prompt echo 已切换到 context-mode: ${name} } cm_list() { if [[ ! -d ${CONTEXT_MODE_HOME} ]]; then echo context-mode: 还未创建上下文目录 ${CONTEXT_MODE_HOME} 2 return 1 fi local current [[ -f ${CONTEXT_MODE_STATE} ]] current$(cat ${CONTEXT_MODE_STATE}) local name for f in ${CONTEXT_MODE_HOME}/*.env; do [[ -e ${f} ]] || continue name$(basename ${f} .env) if [[ ${name} ${current} ]]; then printf * %s\n ${name} else printf %s\n ${name} fi done } cm_status() { local current [[ -f ${CONTEXT_MODE_STATE} ]] current$(cat ${CONTEXT_MODE_STATE} 2/dev/null) if [[ -n ${current} ]]; then echo 当前 context-mode: ${current} else echo 当前 context-mode: (未设置) fi } cm() { local cmd${1:-status} if [[ $# -gt 0 ]]; then shift; fi case ${cmd} in use) __cm_use $ ;; clear) __cm_clear ;; list) cm_list ;; status) cm_status ;; *) echo 用法: cm {list|use name|clear|status} 2 return 1 ;; esac } __cm_init() { mkdir -p ${CONTEXT_MODE_HOME} 2/dev/null || true if [[ $- *i* ]]; then if [[ -f ${CONTEXT_MODE_STATE} ]]; then local current current$(cat ${CONTEXT_MODE_STATE}) if [[ -n ${current} ]]; then __cm_use ${current} return fi fi __cm_set_prompt fi } __cm_init安装步骤三步把脚本保存为~/.context-mode.sh。在~/.bashrc末尾添加source ~/.context-mode.sh。新建~/.context-mode目录至少放一个dev.env然后重新打开终端。之后执行cm list能看到可用上下文执行cm use dev切换执行cm clear退出。提示符会变成类似userhost:~/project [dev]$的样式当前模式一目了然。3.3 为什么必须用函数而不是外部脚本第一次设计这个工具时我想过直接写一个 python 脚本通过参数切换和加载环境变量。试了之后马上发现问题python 脚本运行在子进程里它 export 的变量只影响自己退出后父 shell 完全不受影响。所以切换工具的“切换”动作必须由 shell 函数完成或者用source执行脚本。这也是我不用cm use dev作为一个独立可执行文件的原因。cm是一个函数函数定义在当前 shell 进程里调用时才可能通过export修改当前环境。配置文件用source加载也是一样的道理。如果你把执行逻辑放到子进程里能做到的只有修改 state 文件和下次初始化时的恢复但当前命令行的 API 地址等变量不会立刻变化用起来非常别扭。3.4 进阶让每次切换留下审计日志模式切换最容易出问题的场景是你根本不记得自己什么时候切到了错误模式。所以我后来在__cm_use里加了一个审计点每次切换不仅写 state 文件还追加一行记录到${CONTEXT_MODE_HOME}/switch.loglog_line$(date %Y-%m-%d %H:%M:%S) switch_to${name} user${USER} pwd${PWD} echo ${log_line} ${CONTEXT_MODE_HOME}/switch.log这行日志在排查问题时太有用了。比如你发现某个命令在错误的上下文里执行了直接打开 switch.log 就能看到切换时间和当时所在目录不需要凭记忆复盘。我甚至把cm_use包装成只有通过该函数才能改状态禁止任何人直接改CONTEXT_MODE_NAME变量避免绕过审计。4. 跑了三个月后边界、坑与安全底线4.1 变量残留的清理并没有想象中简单脚本里__cm_clear用了一个粗暴的办法读取旧.env文件的变量名逐个unset。这个办法对大多数值安全但有几个坑。第一个坑是.env文件里如果写了export FOOhello world按切分后 key 是export FOO而不是FOO所以要先把export前缀去掉。第二个坑是如果变量值里有只取第一个前面的字符串就对了如果某个变量名写成带空格的形式过滤正则会直接跳过。第三个坑是如果旧上下文没有显式列出某个变量但你在 shell 里手动 export 过同名变量__cm_clear不会清理它。所以我现在要求每个.env文件必须遵循一个约定一个上下文涉及的全部变量都要显式声明不要依赖切换前 shell 里已有的值。这样可以保证清理逻辑是可预期的。如果一定要保留某些全局变量就把它们放到一个base.env里所有模式加载前先 source 一遍但清理时不要把 base 里的变量清掉否则 PATH 这类变量会被误删。这个边界需要在脚本里显式处理我的实现中是把PATH、HOME、USER这几个系统级变量加入了__cm_protected_keys数组unset前先判断一下。4.2 别用 DEBUG trap 实时刷新上下文提示早期版本我想让提示符在每次命令执行前自动刷新于是用了trap __cm_set_prompt DEBUG。结果交互体验变得极差每次按键、每次补全、每个 git 命令都会触发 DEBUG trap在项目目录里按一次 Tab 都要等上一两秒。原因很简单DEBUG trap 会在每条简单命令之前执行bash 的补全机制会调用大量内部命令全部被钩子拦下来。后来我改成只在cm use/cm clear时调用__cm_set_prompt同时用PROMPT_COMMAND在每次显示提示符前同步一下 state 文件里的内容但不做复杂解析。这样既保证新终端能恢复上次模式又不会拖慢正常操作。这是一个很典型的“功能踩坑”你想要实时更新但实时性带来的成本超过了收益。4.3 给危险上下文加一道保险严格模式context-mode 解决的是变量污染但它不能解决手误。比如有人明明在正式目录却手滑敲了cm use test后边的命令就会在错误模式里跑。为防这种问题我加了严格模式开关。在~/.context-mode/state旁边放一个strict文件里面写需要保护的模式名一行一个。__cm_use开头检查if [[ -f ${CONTEXT_MODE_HOME}/strict ]]; then while read -r protected_name; do if [[ ${name} ${protected_name} ]]; then echo context-mode: 拒绝切换到受保护上下文 ${name}请先编辑 strict 文件确认 2 return 1 fi done ${CONTEXT_MODE_HOME}/strict fi这样就为“正式环境”建立了一道物理隔离哪怕你敲错命令也不会因为一个快捷键直接进入危险模式。真正需要切换时先去把 strict 文件里的名字删掉再操作这个确认过程本身就是一种安全缓冲。类似的思路也可以用在脚本里某个部署脚本在运行前检查CONTEXT_MODE_NAME如果不是预定义的安全模式就直接退出而不是尝试自己猜。4.4 使用建议和边界意识使用 context-mode 三个月后我的体会是它最擅长解决的是一组变量与一种工作状态的强绑定而不是所有状态管理的银弹。上下文越多维护成本越高。每新增一个模式就要新增 env 和 alias 文件还要记住它们之间的差异。所以我的建议是控制在三个以内比如 dev、test、strict再多就会因为切换太频繁而失去意义。另一个建议是把 context-mode 用在一个明确的工作目录树里。比如我规定只有~/work/*下的项目可以随意使用cm use其他地方一律先用cm status确认当前模式。这不是脚本强制而是工作习惯。因为 context-mode 本质上是给终端补上“上下文感知”真正使用时还是需要你自己有一个“当前应该处于什么上下文”的判断。如果你已经有一套 dotfiles 管理机制也可以把~/.context-mode目录整个纳入版本管理这样换新机器时一条命令就能恢复全套上下文配置。我个人目前就是这么做的配置文件跟着 dotfiles 仓库走脚本本身也维护在同一个仓库里机器换了模式还在。