Vivado卸载不是删文件，是做一次系统级“断舍离”
你有没有遇到过这样的场景：
刚卸载完 Vivado 2021.1，兴冲冲装上 2023.2，结果终端里敲vivado -version报错command not found；
或者 GUI 启动后白屏两秒就退出，日志里只有一行ERROR: [Common 17-39] 'cd' failed to change the current working directory to '/opt/Xilinx/Vivado/2020.2/data'；
又或者 IP Catalog 加载极慢，点开全是灰色图标，刷新十次才出来一个……
这些都不是新版本的 Bug，而是旧环境变量在“阴魂不散”。
Vivado 官方卸载脚本（Linux 的uninstall.sh、Windows 的控制面板卸载）干得其实很“干净”——它精准地删掉了/opt/Xilinx/Vivado/2021.1/下所有二进制、脚本、文档和 license 文件。但它完全不管你的 Shell 配置文件里还躺着三行export PATH=...，也不关心.bashrc末尾那个source /opt/Xilinx/Vivado/2020.2/settings64.sh是否还在默默生效。
换句话说：卸载程序清空了房间，但没关掉门牌号——别人照样按老地址敲门，敲开却发现屋里已人去楼空。
而这个“门牌号”，就是环境变量。
为什么PATH是第一个必须动刀的地方？
别小看这一行：
export PATH="/opt/Xilinx/Vivado/2020.2/bin:$PATH"它不是一句注释，而是一条永久生效的路径指令，写进~/.bashrc后，每次你打开新终端，Shell 就会把它加到搜索路径最前面。
这意味着什么？
→ 当你输入vivado，Shell 不会去找你刚装的2023.2/bin/vivado，而是先扑向那个早已被uninstall.sh删得只剩空目录的2020.2/bin/；
→ 如果那里还残留一个损坏的符号链接（比如指向/opt/Xilinx/Vivado/2020.2/lib/lnx64.o/librdi_common.so），而该 so 文件已被删，那vivado进程一启动就会 Segmentation Fault；
→ 更隐蔽的是：VS Code 内置终端、Makefile 中的$(shell vivado -version)、甚至 Jenkins Pipeline 里的sh 'vivado -mode batch...'，全都会继承这个“幽灵 PATH”。
所以清理PATH，本质是切断所有工具对旧安装路径的隐式依赖链。
我们不用暴力覆盖整个PATH（那是自毁长城），而是做一次精准“外科手术”：
# 第一步：看看当前 PATH 里还藏着哪些“老熟人” $ echo $PATH | tr ':' '\n' | grep -
