最直接有效的办法是动态设置PS1，根据hostname或文件标识（如/etc/prod-server）判断服务器角色，用ANSI码区分颜色：生产用红（01;31m）、预发用黄（01;33m）、其余用绿（01;32m）。

SSH 终端里怎么让不同服务器的 shell 提示符颜色不一样

最直接有效的办法是改 ps1，配合服务器 hostname 或 ip 做条件判断。别依赖终端模拟器配色（比如 iterm2 的 profile），那只是本地显示，换台电脑或用 tmux 就失效。

常见错误是硬编码颜色：比如所有服务器都设成 PS1='\[\033[01;31m\]\u@\h:\w\$ '，结果全是红色，根本分不清哪台是生产库。真正该做的是动态识别当前机器角色。

• 在 ~/.bashrc 或 /etc/bash.bashrc 末尾加判断逻辑，优先匹配明确标识（如 hostname 含 prod、db、staging）
• 避免只靠 hostname，有些环境 hostname 是自动生成的（如 AWS EC2 的 ip-10-0-1-5）。可补充检查文件存在性：/etc/prod-server 或 /etc/environment=production
• 颜色用 ANSI 码更稳，别用 tput（某些最小化系统没装 ncurses）；红色建议用 \[\033[01;31m\]（亮红），绿色用 \[\033[01;32m\]，黄色（预警级）用 \[\033[01;33m\]

示例片段：

case "$(hostname)" in
  *prod*|*db*|*master*) PS1='\[\033[01;31m\]\u@\h:\w\$ \[\033[00m\]';;
  *staging*|*test*)    PS1='\[\033[01;33m\]\u@\h:\w\$ \[\033[00m\]';;
  *)                    PS1='\[\033[01;32m\]\u@\h:\w\$ \[\033[00m\]';;
esac

tmux 状态栏怎么按服务器类型显示不同背景色

tmux 本身不感知服务器身份，得靠外部变量驱动。直接改 ~/.tmux.conf 静态配色毫无意义——同一份配置跑在 5 台服务器上，颜色全一样。

关键点在于：让 tmux 读取一个运行时确定的环境变量，比如 TMUX_SERVER_ROLE，再用它控制 status-bg。

• 在登录 shell 初始化阶段（~/.bashrc）设置 TMUX_SERVER_ROLE，值可以是 prod、staging、dev
• ~/.tmux.conf 里用 #(echo $TMUX_SERVER_ROLE) 插值，但注意 tmux 不支持直接嵌套判断，得靠 shell 命令输出固定颜色名
• 更稳妥的做法是生成临时配置文件：每次启动 tmux 前运行脚本，根据 $TMUX_SERVER_ROLE 输出对应颜色的 set -g status-bg 行，再用 source-file 加载
• 别忘了重载：改完要执行 tmux source-file ~/.tmux.conf，否则新窗口不生效

vim / neovim 怎么根据服务器环境自动切换主题（不是配色方案）

这里说的“主题”指 UI 层视觉隔离，比如生产服务器强制启用 cursorline + 醒目行号 + 红色状态栏，而不是换 gruvbox 这类语法高亮方案。

容易踩的坑是把逻辑写在 ~/.vimrc 顶层，导致每次打开 vim 都重新判断，拖慢启动；或者用 autocmd VimEnter 检测，但远程文件可能还没加载完，hostname 拿不准。

• 最佳时机是在 vim 启动参数里注入标识，比如 alias vim='vim -c "let $SERVER_ROLE=\"prod\""，再在 vimrc 里读 $SERVER_ROLE
• 生产环境推荐强制开启 set cursorline 和 set number，并在 statusline 里加显眼标记：%#Error#PROD%*
• neovim 用户注意：vim.cmd() 在 init.lua 里执行比 autocmd 更早，适合做环境适配；但别在 vim.o.background 上做文章——那只是影响语法高亮底色，和安全隔离无关
• 别用插件自动切 theme（如 morhetz/gruvbox 的 auto-switch），它们检测的是本地 OS 或时间，不是服务器角色

Web 终端（如 GateOne、ttyd）如何继承服务器视觉策略

这类工具通常绕过用户 shell，直接调用 /bin/bash --norc，所以 ~/.bashrc 里的 PS1 修改完全不生效。必须从服务端进程层面注入环境。

典型错误是以为改了 nginx 反向代理 header 就能控制终端颜色——没用，终端颜色由 shell 解释器渲染，跟 HTTP 头无关。

• GateOne：在 server.conf 的 shell_command 字段里显式传参，例如 ["/bin/bash", "-c", "export SERVER_ROLE=prod; exec bash -i"]
• ttyd：启动时用 --signal-hup 并配合 --cwd 不够，得用 --env SERVER_ROLE=prod，然后确保你的 login shell 脚本能读这个 env
• 如果用 systemd 管理 ttyd，务必在 .service 文件里写 Environment=SERVER_ROLE=prod，不要指望 ExecStartPre 里 export 的变量能透传到子进程
• 验证方法：在 Web 终端里执行 echo $SERVER_ROLE，必须有输出，否则后续所有颜色逻辑都白搭

真正难的不是设颜色，而是让所有入口（SSH、tmux、vim、Web 终端）读取同一套角色判定逻辑。一旦分散维护，某台生产库漏掉红色提示，就是事故前兆。