环境变量隔离核心是按需分层、避免交叉污染，须结合用户、会话、进程或命名空间机制实现；推荐按项目建独立用户、用shell脚本封装启动环境或systemd --scope双隔离。
新手配置Linux环境变量隔离，核心不是“彻底隔绝”，而是“按需分层、避免交叉污染”。环境变量本身不具备天然隔离能力，必须结合用户、会话、进程或命名空间机制来实现逻辑分离。直接修改全局/etc/profile或~/.bashrc反而容易引发项目间冲突——比如A项目需要Java 8，B项目依赖Java 17，共用JAVA_HOME就会出错。
按项目建独立用户（最简单可靠）
每个项目对应一个系统用户，环境变量写在各自家目录的~/.bash_profile里，登录即生效，互不干扰。
- 创建项目用户：
sudo useradd -m -s /bin/bash proj_a和sudo useradd -m -s /bin/bash proj_b - 为proj_a配置JDK 8：
echo 'export JAVA_HOME=/usr/lib/jvm/java-8-openjdk' | sudo tee -a /home/proj_a/.bash_profile - 为proj_b配置JDK 17：
echo 'export JAVA_HOME=/usr/lib/jvm/java-17-openjdk' | sudo tee -a /home/proj_b/.bash_profile - 切换使用：
su - proj_a或su - proj_b，此时$JAVA_HOME自动区分
用shell脚本封装启动环境（免改系统配置）
不新建用户，也能做到“运行时隔离”：把项目所需变量打包成启动脚本，每次执行前重置环境。
- 在项目根目录下新建
env.sh：
export NODE_ENV=production
export DATABASE_URL="sqlite:///./data.db"
- 启动服务时用
source ./env.sh && npm start，变量只在当前命令链有效 - 更安全的做法是用
env -i bash --rcfile ./env.sh，先清空继承的环境再加载，杜绝父shell污染
借助systemd --scope做资源+环境双隔离（适合服务化部署）
如果项目以服务形式长期运行（如Web API），可用systemd-run --scope临时绑定一组变量和资源限制，退出即销毁，不留痕迹。
- 示例：启动一个内存受限、且只认特定
PYTHONPATH的Python服务
-p Environment="PYTHONPATH=/opt/proj_x/lib" \
-p MemoryMax=256M \
-- python3 app.py
- 该进程看不到宿主
PYTHONPATH，也不能突破内存上限，且进程结束后cgroup自动清理 - 无需改任何配置文件，适合CI/CD或临时测试场景
警惕chroot和单纯export的误区
chroot不能隔离环境变量，它只换根目录；而export VAR=value在当前shell生效，但子进程若被后台化（&）、或由其他用户启动，就完全失效。这两者都不是环境变量隔离的正解。
- chroot内仍会读取
/etc/environment等全局变量，除非你手动清空并重设 -
export写进~/.bashrc看似一劳永逸，但多个项目共用同一用户时，变量会层层叠加甚至覆盖 - 真正安全的隔离，一定是“用户级”或“进程级”的边界，而不是靠路径或变量名拼凑
