核心是按需注入环境变量：为各业务组创建专属脚本并按组权限控制，登录时动态加载；支持显式激活与systemd用户服务硬编码，禁用全局配置防污染。
在多用户共享服务器上为不同业务组隔离专属环境变量，核心不是“统一配置”，而是“按需注入”——让每个组的会话只加载自己需要的变量，互不干扰、不可越界。
按用户组分发独立的环境配置文件
避免把所有变量写进 /etc/profile 或全局 /etc/profile.d/。应为每组创建专属脚本，放在统一位置并按组权限控制：
- 新建目录 /etc/profile.d/groups/（仅 root 可写）
- 为业务组 A 创建 /etc/profile.d/groups/team-a.sh，内容如：
export APP_ENV=prod && export LOG_LEVEL=warn && export PATH="/opt/team-a/bin:$PATH" - 设置权限：chown root:team-a /etc/profile.d/groups/team-a.sh && chmod 640 /etc/profile.d/groups/team-a.sh
- 在 /etc/profile 末尾追加：
if [ -n "$GROUPS" ] && [ -f "/etc/profile.d/groups/$(id -gn).sh" ]; then . "/etc/profile.d/groups/$(id -gn).sh"; fi
这样，只有属于 team-a 组的用户登录时，才会自动加载 team-a.sh 中的变量，其他组完全不可见、不可读。
用 shell 启动逻辑实现运行时动态加载
对需要更高灵活性的场景（如同一用户属多个组但只启用某组环境），可跳过 profile 自动加载，改用显式命令：
- 在 /usr/local/bin/activate-env 中写一个轻量工具：
#!/bin/bash
case "$1" in
team-a) source /etc/profile.d/groups/team-a.sh ;;
team-b) source /etc/profile.d/groups/team-b.sh ;;
*) echo "Usage: activate-env {team-a|team-b}" >&2; exit 1 ;;
esac - 设为所有人可执行：chmod +x /usr/local/bin/activate-env
- 用户只需在终端中运行 activate-env team-a，即可临时注入该组全部环境变量，退出当前 shell 即失效，无残留
配合 systemd 用户服务做进程级隔离
若业务以 systemd --user 服务方式运行（如定时任务、后台守护进程），环境变量必须在服务单元中硬编码，不能依赖 shell 配置：
- 编辑 ~/.config/systemd/user/myapp.service
- 在 [Service] 段添加：
Environment=APP_ENV=staging
Environment=CONFIG_PATH=/etc/team-b/config.yaml
Environment=PATH=/opt/team-b/bin:/usr/local/bin:/usr/bin - 禁止继承用户 shell 环境：UnsetEnvironment=*（防止意外泄露）
- 启用时执行：systemctl --user daemon-reload && systemctl --user start myapp
这种写法确保即使用户手动修改了 shell 的 PATH 或 APP_ENV，也不会影响服务实际运行环境。
禁用跨组污染的关键守则
环境变量隔离失败，往往源于几个常见疏漏：
- 不把变量写进 /etc/environment —— 它由 PAM 加载，对所有用户生效且不支持条件判断
- 不在 ~/.bashrc 中用 export 全局覆盖 PATH；若必须扩展，用 PATH="$PATH:/new/path" 而非 PATH="/new/path"
- 图形界面程序（如 VS Code、PyCharm）默认不读取 .bashrc，需在 ~/.profile 中补全关键变量，或通过桌面启动器显式指定环境
- 检查是否误启用了 systemd --global 服务，这类服务运行在 root 上下文，会绕过所有用户/组级隔离逻辑
