PATH未正确加载导致command not found，PS1异常因初始化脚本未执行或赋值错误，登录卡顿多由启动脚本中阻塞操作引起，GUI与终端环境不一致源于配置文件加载路径差异。
登录后命令找不到或报 command not found
常见于 PATH 未正确加载，尤其在非交互式 shell（如通过 ssh 执行单条命令）或 shell 配置文件被跳过时。检查当前 PATH：echo $PATH，对比正常用户或 root 的输出。重点排查：~/.bashrc、~/.bash_profile、/etc/profile 中是否漏写了 export PATH=...，或存在语法错误导致后续行未执行。注意：某些发行版（如 ubuntu）默认只读取 ~/.profile，而 ~/.bashrc 可能未被 sourced；SSH 登录时若使用 ssh user@host command，通常不触发 ~/.bashrc。
PS1 未生效或提示符显示异常
说明 shell 初始化脚本未完整执行，或 PS1 被覆盖/清空。先确认当前 shell 类型：echo $SHELL，再检查对应配置文件中 PS1= 赋值是否被注释、拼写错误（如写成 PS12），或被后续的 unset PS1 清除。常见陷阱：~/.bashrc 开头有 [ -z "$PS1" ] && return —— 这会导致非交互式 shell 提前退出，但某些桌面环境或终端模拟器会误判 shell 状态；另外，如果 PS1 值中含未转义的 $ 或反引号，可能导致变量展开失败或命令执行报错。
登录卡在「正在设置环境」或长时间无响应
大概率是某个启动脚本中执行了阻塞操作，比如：ping、curl、git pull 等网络请求超时，或调用了挂起的设备（如已拔出的 usb 存储挂载点）。用 strace -f -e trace=execve,openat,connect bash -l -i 2>&1 | head -50 可捕获登录过程中实际执行的命令和打开的文件。重点关注：~/.bashrc 末尾是否误加了 sleep、read 或交互式命令；/etc/profile.d/*.sh 中是否有脚本尝试访问不可达主机；以及 ~/.profile 是否意外调用了需要 TTY 的程序（如 gpg-agent --daemon 在无终端时卡住）。
图形界面登录后终端内环境与 GUI 应用环境不一致
这是因为桌面环境（GNOME/KDE）通常绕过 shell 配置文件，直接从 ~/.profile 或 D-Bus 会话环境继承变量，而终端模拟器（如 gnome-terminal）可能启动的是 login shell 或 non-login shell，加载路径不同。验证方法：env | grep -E '^(PATH|HOME|LANG)' 分别在 GUI 应用（如文本编辑器的终端插件）和独立终端中运行，对比输出。修复建议：把关键环境变量（如 PATH、EDITOR）统一写入 ~/.profile（它会被 GUI 和 login shell 共同读取），避免仅依赖 ~/.bashrc；若必须用 bash 特性，可在 ~/.profile 末尾显式添加 [ -f ~/.bashrc ] && . ~/.bashrc。
真正麻烦的往往不是哪一行配置错了，而是多个配置文件之间相互覆盖、条件判断逻辑冲突，或者 shell 类型和登录方式组合出的隐式行为差异——查的时候得盯住 $0 和 $- 的值，它们比任何文档都诚实。