最近我给自己的 PC 装了 Win11 和 Debian 12 双系统。在把原本运行在 Windows Docker 里的 Taiga 项目迁移到 Debian 的过程中，踩了不少坑，也学到了不少 Linux 调优的干货。今天把这些经验总结出来，分享给有类似需求的朋友。

一、 Taiga 数据迁移：SQL 才是“硬通货”

很多人（包括我）第一反应是想直接复制 Docker 的镜像和卷文件。但从 Windows 迁移到 Linux，底层文件系统和权限差异巨大，直接拷文件极易失败。

最稳妥的方法：

  1. 在 Windows 上： 用 pg_dump 把数据库导成一个 .sql 文件，再用 docker cp 把媒体文件（media 文件夹）拷出来。
  2. 在 Debian 上： 重新启动一套干净的 Taiga Docker，然后把 .sql 导入新库，再把媒体文件覆盖回去。

心得： 镜像可以重新 pull，但数据一定要用最通用的方式导出。

二、 内网穿透后的“跨域”难题

迁移完成后，我用 frp 将本地的 9000 端口映射到了公网 VPS。结果一访问，满屏的 CORS 报错和 WebSocket 连接失败。

原因： Taiga 的前端代码里记住了它原本的地址是 192.168.0.120。当你从公网访问时，浏览器会拦截这种“从公网请求内网”的行为。

解决： 修改 Taiga 根目录下的 .env 文件，将 TAIGA_SITES_DOMAIN 设置为你的公网 IP 或域名。重启容器后，前端就会乖乖地向公网地址发起请求，报错瞬间消失。

三、 在 Debian 里优雅地访问 Windows 桌面

双系统最常做的事就是在 Linux 里翻 Windows 的文件。

操作要点：

  1. 别用默认挂载： 在 /etc/fstab 里如果只写 defaults，你会发现挂载出来的文件全是 root 权限，普通用户根本改不了。
  2. 正确姿势： 在挂载参数里加上 uid=1000,gid=1000。这样 Linux 就会认为这些 Windows 文件是你当前用户创建的。
  3. 安全第一： 记得加上 nofail 参数。万一哪天 Windows 磁盘出问题了，Debian 还能照常开机，不至于卡死在启动界面。

四、 消失的 1 秒钟：彻底解决 sudo 延迟

这是最玄学的一个点：每次输入 sudo，都要卡 1 秒钟才跳出密码框。

排查发现： 这是因为 sudo 在启动时会去检查你的“主机名（Hostname）”。如果你的主机名设置成了 debian.example.com 这种格式，而你又没有在本地告诉系统这个名字对应的 IP，系统就会满世界去问 DNS 服务器，直到 1 秒钟后超时。

解决： 编辑 /etc/hosts，在 127.0.0.1 后面把你那长长的主机名加上去：

1

127.0.0.1   localhost your-long-hostname

改完之后，sudo 秒开，那种丝滑感真的太爽了！

五、 番外篇：Git 提交时的“非快进”报错处理

在这次迁移中，我还遇到了一个 Git 的经典报错：[rejected] main -> main (non-fast-forward)。

为什么会报错？

简单来说：远程仓库（GitHub）已经包含了你本地仓库里没有的提交（Commits）。 Git 默认只允许“快进式”推送，如果你的提交不是基于远程最新版本的“延伸”，它就会报错防止代码被覆盖。

解决思路：

  1. git stash：如果你本地还有没写完的代码，先用这个命令把它们“藏”起来。
  2. git pull --rebase：这是最优雅的做法。它会把你的本地提交先“拆下来”，把远程最新的提交“接上去”，然后再把你的提交重新“补”在最后面。
  3. 解决冲突：如果本地和远程改了同一个地方，手动删除 <<<<<<< HEAD 这种标记并保留正确内容。
  4. git rebase --continue：告诉 Git 冲突解完了，继续剩下的工作。

这种处理方式能让你的 Git 提交历史保持一条直线，非常整洁。

结语

折腾 Linux 的乐趣就在于：遇到一个看似莫名其妙的问题，通过查看日志、分析原理，最后一行代码精准修复。希望这篇记录能帮到正在双系统之路上摸索的你！