vscode终端默认启动非登录shell，不加载.bash_profile而只加载.bashrc，且可能因守卫逻辑跳过.bashrc；可靠方案是统一将环境变量移至.bashrc并添加vscode_ipc_hook识别。
VSCode 终端启动的是登录 Shell 还是非登录 Shell？
VSCode 集成终端默认启动的是 非登录 Shell（non-login shell），哪怕你用的是 Bash。这意味着它 不会自动读取 .bash_profile，只读取 .bashrc —— 除非你手动配置为登录模式。
这和你在终端应用里直接打开一个新窗口（如 GNOME Terminal、iTerm2）行为一致，但和 SSH 登录、或 bash --login 完全不同。
- 验证方式：在 VSCode 终端运行
shopt login_shell，输出login_shell off即确认为非登录 Shell - 影响：你在
.bash_profile里设置的export PATH、export JAVA_HOME等变量，不会生效 - 常见现象：VSCode 终端里
which java找不到，但系统终端里可以 —— 很可能就是.bash_profile没加载
为什么 .bashrc 有时也不加载？
VSCode 默认使用当前用户的 $SHELL，但它不保证会执行 ~/.bashrc 的全部逻辑 —— 尤其当你的 .bashrc 开头有类似 [ -z "$PS1" ] && return 这类“仅限交互式 Shell”的守卫逻辑时，VSCode 终端可能被判定为非交互式（尽管实际是），导致提前退出。
微软正式发布 Visual Studio Code 1.118 版本 。本次更新重点强化了 AI 开发体验与企业管理能力，其中最引人注目的是新增 Copilot CLI 远程控制功能，允许开发者通过手机或网页远程监控和接管 AI 会话 。同时，为了提高 AI 的运行性价比，新版本优化了令牌缓存策略以降低成本 。此外，1.118 版还引入了 Chronicle 本地历史追踪、TypeScript 7.0 支持以及更严格的企业级访问管控 。
- 检查是否加载：
echo "loaded" >> /tmp/bashrc_test加到.bashrc开头，重启 VSCode 终端后看文件是否存在 - 典型守卫语句：
[[ -z $PS1 ]] && return或if [[ $- != *i* ]]; then return; fi—— 这些会跳过整个.bashrc - VSCode 终端的
$-值通常是himBH（含i），但某些旧版本或远程扩展可能不设i标志
如何让 VSCode 终端可靠加载环境变量？
最稳妥的做法不是改 VSCode 设置，而是统一入口：让 .bashrc 成为唯一可信的初始化来源，并确保它被非登录 Shell 正确执行。
- 确认
.bash_profile末尾有标准加载逻辑：if [ -f ~/.bashrc ]; then . ~/.bashrc; fi - 把所有关键环境变量（
PATH、SDKMAN_DIR、GOBIN等）移到.bashrc，并去掉守卫逻辑，或改为更宽松判断：if [[ $- == *i* ]] || [[ -n "$VSCODE_IPC_HOOK" ]]; then - VSCode 会注入
VSCODE_IPC_HOOK环境变量，可作为识别信号；加这一条能避免破坏其他场景 - 避免在
.bashrc里写cd命令——它会在每次新开终端时执行，干扰工作目录
要不要改 VSCode 的 terminal.integrated.profiles.*？
可以，但不推荐作为主方案。强行配置 "args": ["-l"]（即 bash -l）会让终端变成登录 Shell，从而加载 .bash_profile，但副作用明显：
- 可能触发重复加载（比如
.bash_profile又 source.bashrc，而.bashrc里又有守卫逻辑） - 某些插件（如 Remote-SSH）会覆盖该配置，导致行为不一致
- WSL 场景下，
-l可能引发 systemd 用户 session 冲突，终端卡住 - macOS 上 Terminal.app 和 VSCode 行为差异变大，不利于团队统一
真正容易被忽略的点是：VSCode 终端的环境继承自父进程（即 VSCode 进程本身），而 VSCode 启动方式（桌面图标、命令行、launchd）决定了它初始的环境变量快照 —— 如果你从 Dock 启动 VSCode，它根本看不到你 shell 里 export 的变量。所以，靠 shell 配置文件补救，永远不如在 VSCode 启动前就让环境就绪。
