那天我想把一套已经在日常工作中使用的知识库，同步到局域网里的另一台 Windows 电脑。最初的问题听起来很简单：这套东西能不能直接迁过去？如果不能，Windows 还需要做哪些适配？
我一开始也差点把它理解成一次普通的目录复制。把文件打包，传到目标机器，找到入口，运行一条命令，看到它没有报错，似乎就可以宣布完成了。可是继续检查后，我发现真正需要迁移的并不是一个目录，而是几种性质完全不同的东西：能被版本控制的源码、只属于当前机器的事实、运行过程中生成的证据，以及依赖这些事实建立起来的索引。
跨平台迁移的关键，不是把原机器上的所有东西搬过去，而是判断哪些东西在目标机器上仍然为真。
表面上是换系统，实际上是换事实
这套知识库的主体并不复杂。它主要由纯 Python 脚本组成，依赖 Python、git 和 SQLite，没有发现必须绑定某个系统的核心组件。从“代码能不能运行”这个角度看，它确实可以跨平台同步。
但“主体可以同步”和“整个知识库可以照搬”不是一回事。知识库在运行时会认识一些本地目录、仓库和工具，并把这些关系记录下来。它记录的不是抽象概念，而是某台机器上实际存在的路径和状态。
当我看到目标机器上的旧注册表仍然指向原机器的绝对路径时，这个区别就变得很具体了。那几条记录在原机器上可能完全正确，换到 Windows 后却只剩下一个看起来完整的地址。路径还在，目标却不在了。
如果不处理这个问题，后面会出现一种比直接报错更麻烦的结果：知识库能够启动，查询也可能返回结果，但这些结果来自另一台机器的事实。它会把“原机器曾经认识什么”误当成“目标机器现在有什么”，最后得到一个看似绿色、实际失真的系统。
这件事让我重新意识到，跨平台迁移不只是换了操作系统，也换了事实来源。代码可以追求一致，机器事实必须允许不同。
先把资产分成4类
为了不被“整个目录”这个说法带偏，我把需要处理的内容拆成4类。
第一类是可复制的源码，包括脚本、说明和测试。它们描述的是知识库如何工作，只要依赖条件满足，就应该尽量保持一致。这部分适合通过同步工具传输，也适合用版本和逐文件哈希校验来确认没有被改坏。
第二类是机器本地事实，例如目标机器上的工作目录、仓库位置、已经安装的环境和当前可访问的资源。这些内容不能从原机器推断。它们要在目标机器上重新发现，或者由目标机器的实际路径重新登记。
第三类是运行态目录，也就是程序执行后留下的缓存、临时数据和生成物。它们有时很大，有时很有诱惑力，因为复制它们看起来能让新机器“立刻拥有历史”。但它们通常混合了当前机器的路径和状态，适合排除在源码同步之外。
第四类是证据库和索引。它们不是简单的资料备份，而是对某台机器、某个时间点的事实整理。尤其是用 SQLite 保存的证据库，虽然文件本身跨平台可读，却不代表里面的路径和结论跨机器仍然有效。
能被 SQLite 打开的文件，不等于其中记录的事实适合另一台机器。
这个分类的价值，在于它把“能不能传”改成了4个更准确的问题：它描述的是规则，还是事实？它能否独立重建？它是否包含原机器的路径？它失效后有没有更安全的重建方式？
最容易误判的是证据库
错误捷径是把整个目录打包复制过去，然后只看入口是否能启动。这种做法很像搬家时把所有箱子都贴上“重要”标签，省去了分类，却把问题留到了入住以后。
证据库尤其容易制造假象。它已经有记录、有数量、有索引，打开后不像空白项目，人的第一反应会是“迁移很成功”。可是如果记录里的路径来自原机器，目标机器查询到的可能只是大量缺失项。原机器的证据越完整，错误的确定感反而越强。
我没有选择直接复制证据库，是因为它的价值依赖生成它的环境。目标机器需要知道自己的目录在哪里、哪些仓库真实存在、当前使用的版本是什么。把原机器的答案复制过去，并不能替目标机器完成这次调查。
这并不意味着原证据没有价值。它可以作为迁移前的参考、备份或对照，用来帮助判断哪些内容应该在目标机器重新建立。但它不应该伪装成目标机器已经验证过的本地知识。
我选择先同步源码，再重建本地层
这次我的决策顺序是：先备份，再同步可复制的源码；排除运行态目录；到 Windows 侧根据本地事实重建注册表和知识库；最后才做冒烟验收。
我选择这个顺序，是因为它把不可逆的错误压缩在最小范围内。源码同步失败，通常可以依据哈希重新传输；本地事实识别错了，也可以修改目标机的登记；但如果把旧证据当成新事实，后续的查询、分析和判断都会在错误的基础上继续累积。
同步过程本身也不能只看“传输了多少文件”。这次同步脚本支持选择目标机器，执行前会备份目标侧已有内容，完成后还会做逐文件哈希校验。备份解决的是回退问题，哈希解决的是完整性问题，两者都不能替代本地重建，但能让源码迁移变得可验证、可恢复。
目标机器收到源码后，入口确实能够运行，说明跨平台主体的判断成立。但这只是第一道门，不是最终结论。随后检查注册表时，仍然能看到原机器绝对路径造成的缺失记录，这正好证明了为什么不能把“入口能启动”当作知识库已经迁移完成。
适配不是改代码，而是重建认识
这次 Windows 侧真正需要的适配，比我预想的少，也比目录复制多。
少的部分是核心代码：没有必要为了换系统重写一套实现，也没有必要先增加复杂的兼容层。只要 Python、git 和 SQLite 在目标机可用，主体就具备运行条件。
多的部分是本地认识：旧注册表要改成目标机器自己的路径，原机器生成的证据库不能直接当作现状，排除的运行态目录要在目标侧按需重建。知识库不是被动读取一堆文件，它还需要形成“这台机器有什么”的判断。
还有一个小但实际的差异：Windows 上手动运行时使用的是 python，而不是另一套系统上常见的 python3。这不是知识库逻辑变化，却会影响现场验收。目标机器的入口命令、解释器版本和 git 版本都应该以目标侧实际输出为准，而不是沿用原机器的操作习惯。
如果出现中文或符号显示异常，也要把它和功能故障分开。Windows 控制台的默认编码可能让输出出现乱码，但这不等于数据库或脚本已经损坏。先判断数据和命令是否正常，再决定是否调整输出编码，能避免把展示问题误判成迁移失败。
一套可以复用的迁移流程
以后再迁移类似的本地知识库，我会先做一张资产表，而不是先找压缩工具。每项内容只需要回答4件事：它是源码、机器事实、运行态，还是索引证据；它是否包含绝对路径；它能否在目标机器重建；它应该复制、排除、备份，还是重新生成。
接着做源码同步。同步前保留目标侧备份，明确目标机器和目标目录，不用模糊的名称自动猜位置。同步后做逐文件哈希校验，确认传过去的是同一份源码，而不是“看起来差不多”的副本。
然后处理本地事实。让目标机器重新登记自己的目录、仓库和环境，把原机器的记录只当作参考。原有索引如果包含机器路径，就不要直接复用；能重建的就重建，不能重建的就保留为迁移前备份，不要混进目标侧的当前状态。
最后才做验收。验收至少要包含目标机器上的解释器和版本、目标路径是否真实存在、知识库入口能否运行，以及一条最小查询是否返回符合目标环境的结果。Windows 侧命令要用它自己的命令形式，不能因为原机器上的命令曾经成功，就跳过这一步。
一个跨平台迁移真正完成的标志，不是文件出现在目标目录，而是目标机器能用自己的事实重新证明它为什么可信。
下次我会怎么做
下次遇到“能不能把这套系统搬到另一台电脑”时，我会先问自己：我要搬的是规则，还是某台机器对规则运行后的记忆？如果答案是前者，就同步源码；如果答案是后者，就先判断这些记忆是否绑定路径、环境和时间。
我也会把“能启动”和“能工作”分成两个验收点。前者只说明依赖和入口没有立刻失败，后者还要证明路径属于目标机器、索引来自目标事实、查询结果没有继承原机器的幻觉。中间少掉的这一步，往往正是迁移最容易失真的地方。
这件事让我重新理解了备份。备份不是把所有东西都复制一份，而是让真正需要保留的内容可恢复，让不该冒充现状的内容被隔离。源码需要一致，证据需要可信，索引需要重建，机器事实需要重新确认。把这4件事分开，迁移就不再是一次冒险的搬家，而是一套可以重复执行的工作方法。