这页能直接回答的问题
- 哪些值更适合放环境变量，而不是写进配置文件？
- 怎么判断 shell 是不是在覆盖文件配置？
- 什么时候该停止依赖环境变量，转成更稳定的配置路径？
做完后该核对什么
- 在真正工作的 shell 里列出相关环境变量。
- 比较变量存在和移除之后的行为差异。
- 如果清掉 env 覆盖后问题还在，再回到配置文件路径排查。
最常见的误区
- 把环境变量当成默认就自解释的东西。
- 忘了不同终端 profile 可能导出不同值。
- 长期用环境变量顶着，明明写进稳定配置文件会更好理解。
环境变量
环境变量只有在你清楚当前是哪一组 shell 值在生效时，才会真正帮助 DeepSeek TUI
环境变量改起来很快，但一旦多个 shell、profile 或项目脚本同时存在，它们也最容易把你原本以为会生效的配置静默覆盖掉。
本页是站内详情页DeepSeek TUI 的环境变量怎么用配置
推荐阅读顺序
先按当前问题走，再决定要不要切去相邻详情页或 hub。
先决定哪些值应该本地化
环境变量更适合机器本地或会话级的敏感值，不适合默认承载一切配置。
记清它们从哪来
知道变量到底来自 shell profile、direnv 类工具、CI，还是一次性的 export。
跨 shell 比较
如果一个终端正常、另一个不正常，先对比环境变量状态，再决定要不要改配置文件。
直接可用的示例
先拿可执行例子，再回头做更细的调整。
先看当前 shell 到底导出了什么
尤其当不同终端行为不一致时，先把相关值列出来，再动配置文件。
echo "$DEEPSEEK_API_KEY"
# 再检查当前 shell 里的 provider 相关导出做一次有无覆盖的对照
想快速证明 env 层是不是在作怪，最直接的方法就是清掉相关导出后再比一次。
unset DEEPSEEK_API_KEY
# 重开 shell 或重试最窄请求路径常见失败分支
先判断你卡在哪一层，再去对应分支，不要把所有问题都混成一个。
一个终端正常，另一个终端不正常
这通常不是 provider 掉了，而是 shell profile 差异。先对比两个 shell 的导出值。
你改了配置文件，但行为完全没动
很可能环境变量覆盖还在赢。先把 env 值查清楚，再判断是不是文件路径问题。
什么时候该离开这页
当你已经确认当前路线没问题，就不要继续停留在这页。安装线应转去配置，配置线应转去 provider 或排错，MCP 和模式线则应该转回真实工作流页。详情页的价值是把问题缩窄，而不是长期停留在解释层。