症状： Julia 1.13 已发布，但旧项目、科研包和论文复现实验不能确定是否安全。
最快解法： 第一周不要覆盖正式环境，先锁定旧版本与结果，建立独立测试环境，完成包兼容和数值回归，再决定升级、双轨或暂缓。
这份清单适合 3 类人：维护 Julia 科研包的开发者，可用它安排兼容性与 CI 检查；准备升级课题环境的研究生，可据此判断论文复现风险；管理多人课题组环境的技术人员，可据此制定版本冻结与回退流程。
最后更新于 2026 年 9 月 23 日，版本信息核实自 Julia 官方下载页、Julia 1.13 发布说明 与官方文档。Julia 补丁版本、生态包支持状态或重要回归出现后，应重新复核本文。
发布当天先把正式环境冻结
截至 2026 年 9 月 20 日，Julia 官方下载页显示 Julia 1.13.0 于 2026 年 9 月 9 日发布，并列为当前 Stable 版本，同时提供 Stable、LTS、旧版及不同平台安装信息。官方发布说明还指出，这是 1.x 系列中的次版本发布，包含新功能和行为调整；这并不等于你的科研项目可以跳过验收。(julialang.org)
你需要先保存以下内容：
- 当前 Julia 版本，以及启动参数、环境变量和
startup.jl。 - 项目的
Project.toml、Manifest.toml、脚本入口和数据处理说明。 - CI 配置、测试日志、代表性输入文件与输出文件。
- 论文或课题中最关键的数值结果、图形、收敛信息和异常记录。
- 当前环境的恢复方法，包括 Julia 安装来源、包缓存位置和权限要求。
Manifest.toml 不是可有可无的依赖列表，而是当前环境中直接依赖和间接依赖的精确记录。官方 Pkg 文档说明，Project.toml 与 Manifest.toml 配合使用，可以实例化接近原状态的包环境；从 Julia 1.10.8 开始，还可以使用按 Julia 小版本命名的 Manifest 文件，例如 Manifest-v1.11.toml。(pkgdocs.julialang.org)
这一步的隐性成本在于：如果你只保存代码、不保存环境，之后即使重新安装同名包，也可能得到不同的依赖解析结果；如果只保存最终图表、不保存原始输入和容差标准，就无法判断新版本造成的是数值变化、数据变化，还是绘图流程变化。
第一小时建立隔离版本，而不是覆盖旧版本
Julia 官方建议典型安装使用 juliaup，它可以安装指定版本并处理路径管理；官方平台说明也列出了 macOS 与其他平台的安装路线。你应优先使用官方安装来源，不要把系统包管理器提供的版本当作课题组唯一基线。(julialang.org)
可以按下面的顺序操作：
-
复制项目目录。
将旧项目复制到独立分支或新的工作目录，保留原始Project.toml、Manifest.toml和测试数据。 -
安装 Julia 1.13。
使用juliaup或官方二进制安装 Stable 版本。安装完成后记录versioninfo()输出、安装路径和架构信息。 -
明确 Apple Silicon 与 Intel 路线。
如果课题组成员使用 Apple Silicon，不要只验证 Rosetta 或 x86 路径。分别记录原生架构、二进制依赖和需要重新编译的包；Julia 官方下载页已经区分 macOS Apple Silicon 安装文件。(julialang.org) -
复制环境而不是重新自由解析。
优先用项目现有的 Manifest 恢复环境，再单独尝试升级依赖。这样可以区分“Julia 版本变化”与“包版本同时变化”造成的问题。 -
保存安装日志和恢复命令。
至少记录 Julia 版本、激活目录、包实例化命令、预编译结果和失败日志。多人课题组不能只依赖某一位成员的记忆恢复环境。 -
确认回退路径。
旧 Julia、旧 Manifest、旧测试数据和旧 CI 配置必须仍然可用。若新环境出现无法解释的结果差异，你应能在同一天内回到旧环境继续工作。
在这一阶段，Julia 1.13 的安装成功不代表科研项目升级成功。真正的通过标准是：项目能恢复、核心包能加载、最小测试能运行，而且旧环境仍然可复现。
第一天用核心包和数值回归判断风险
Julia 包兼容不能只看包管理器是否完成解析。Project.toml 中的 [compat] 约束会限制 Julia 和依赖包的可用版本；如果项目没有明确约束，Pkg 可能把项目视为兼容更宽泛的版本范围。官方兼容性文档对版本约束和语义化版本规则有详细说明。(pkgdocs.julialang.org)
建议把项目测试分成 4 层：
1．加载与接口层
先检查核心包是否能够正常 using，再运行项目最常用的函数。重点记录：
- 方法不存在、导出名称变化和弃用警告；
- 类型转换、关键字参数和默认值变化；
- 文件读写、序列化和配置读取是否一致；
- 依赖二进制库是否能在目标架构加载。
2．最小数据层
不要一开始就运行完整课题数据。先准备一组规模较小、结果已知的输入，验证预处理、模型构建、求解和结果导出链路。这样可以把包兼容问题与数据规模、内存压力和长时间运行问题分开。
3．数值回归层
对每个核心模型保存以下证据：
- 标量结果与允许误差；
- 向量或矩阵的最大绝对差、相对差；
- 迭代次数、收敛状态和残差；
- 图形中的坐标范围、峰值位置和图例；
- 随机过程使用的种子、采样数量和输出摘要。
浮点数出现微小差异并不必然意味着升级失败，但你必须能解释差异来源。排序顺序、随机数流、线程调度、线性代数后端或包内部算法都可能影响结果；论文复现尤其不能只比较“程序退出码为 0”。
4．异常与边界层
刻意运行缺失值、空输入、极端参数、非法路径和中断场景。很多兼容问题不会出现在标准样例中，而会在错误处理、日志格式和边界输入下暴露。
Pkg 官方文档建议使用 add、compat、update 等命令管理依赖，而不是手工改写 Manifest。对需要固定包版本的课题，应把兼容约束写入项目文件，并把环境文件纳入版本控制。(pkgdocs.julialang.org)
用对比结果决定升级、双轨还是暂缓
到了第一周中段，你不需要凭感觉争论“新版本是否更好”，而应把决定拆成可检查的条件。
| 决策结果 | 适用条件 | 你需要保留的证据 | 主要风险 |
|---|---|---|---|
| 升级正式环境 | 核心包可解析，数值回归通过，CI 通过，成员能恢复环境 | 测试日志、结果差异说明、回退提交 | 个别低频脚本可能尚未覆盖 |
| 双轨运行 | 主流程基本通过，但仍有包、架构或成员机器未确认 | Stable 与旧版本的环境文件、差异清单 | 维护两条环境会增加文档和 CI 成本 |
| 暂缓升级 | 核心包不兼容、结果差异无法解释、论文临近提交或回退困难 | 失败日志、问题包版本、复核日期 | 错过新版本改进，但可保护课题复现 |
| 新项目采用 Stable | 没有历史结果需要对照，依赖范围清晰，测试从一开始就纳入 CI | 初始环境文件、测试基线和安装说明 | 早期生态问题仍需持续观察 |
评分时可以给每个项目维度打 0—2 分：
- 包兼容：0 分表示无法解析，1 分表示主流程可用但有已知问题，2 分表示核心包和异常路径均通过。
- 数值一致性：0 分表示差异无法解释，1 分表示部分结果需复核，2 分表示所有关键指标符合项目容差。
- CI 完整度：0 分表示没有新版本测试，1 分表示只有单一系统，2 分表示已覆盖课题真正使用的版本和系统。
- 回退能力：0 分表示无法恢复，1 分表示需要人工排障，2 分表示按文档即可恢复。
- 课题时机：0 分表示论文或实验处于不可中断阶段，1 分表示可以安排窗口，2 分表示新项目或低风险阶段。
如果总分偏低，不要因为 Julia 1.13 是 Stable 就强行切换。Stable 代表官方发布路线，不代表所有第三方科研包、二进制依赖和课题脚本已经完成同一时间点的验证。
第一周把 CI、文档和 Apple Silicon 验收补齐
CI 的目标不是证明“某台机器能运行”，而是尽早发现版本、操作系统和架构之间的差异。Julia 生态提供的 setup-julia 支持指定版本、版本范围和矩阵测试；其文档还特别提醒，YAML 中的版本应使用字符串，否则类似 1.10 的值可能被解析成其他数字。(github.com)
一个面向课题组的最小矩阵可以包含：
julia-version: ["旧版本", "1.13"]
os: [ubuntu-latest, macos-latest]
不要机械复制这个示例。你应根据课题实际交付环境决定是否增加 Windows、Intel macOS、Apple Silicon 自托管 Runner 或特定 Julia LTS 路线。GitHub 官方文档说明，矩阵策略可以用同一个任务定义测试多个语言版本和操作系统组合，但矩阵扩大后也会增加运行时间和失败排查量。(docs.github.com)
第一周至少完成以下检查：
- CI 是否明确打印
versioninfo()和架构信息； - 包测试是否使用项目自己的 Manifest；
- 测试失败时是否保留完整日志和生成文件；
- 图形、模型输出和基准输入是否有可比较的快照；
- README 是否写清安装、激活、测试和回退命令；
- 课题组成员是否能在自己的机器上恢复，而不是只有管理员能恢复；
- Apple Silicon 上是否使用了正确架构的 Julia 和二进制依赖；
- 远程登录、文件传输和权限是否足够完成完整验收。
如果你需要比较 Mac Stable 与 LTS 的长期路线，可以先阅读 Julia 版本选择与环境冻结说明，再把结论写入维护记录，而不是只写“以后再看”。涉及 macOS 科研依赖的成员，也可以结合课题组内部的设备管理与远程访问规范，提前确认责任划分。
没有 Mac 时完成 Apple Silicon 验收
没有 Mac 不等于无法测试 macOS 路径，但你需要区分 3 种目标：
- 验证 Julia 和科研包能否在 macOS 上安装、解析和运行。
- 验证 Apple Silicon 原生架构下的二进制依赖与脚本行为。
- 验证真实课题数据、外设、权限或本地文件系统集成。
前两项可以通过远程真实 Mac 完成。你可以建立隔离账户或项目目录，使用 SSH 执行安装与回归脚本，再通过 VNC 检查图形界面、绘图输出和需要交互操作的工具。远程真实 Mac 适合在短期升级窗口内补足实验室缺少的 macOS 设备；但它不能替代对专用仪器、USB 外设、校内网络策略和本地数据合规要求的验证。
建议远程验收按 5 步进行：
- 记录远程主机的 macOS 版本、芯片架构和 Julia 安装来源。
- 上传或拉取项目的
Project.toml、Manifest.toml与最小测试数据。 - 使用 Julia 1.13 原生架构实例化环境，保存包解析与预编译日志。
- 运行同一套核心包测试、数值回归和图形导出任务。
- 将结果与 Linux、Windows 或旧 Mac 环境进行对照，并记录哪些差异属于平台特性。
不要把远程 Apple Silicon 测试结果包装成“所有 Mac 都兼容”。不同 macOS 版本、系统权限、二进制依赖、图形后端和数据路径都可能改变结果；你能确认的是某个明确环境下的验收结论。
第一周结束时写下长期维护决定
在维护记录中明确写出以下内容：
- 当前正式环境仍使用哪个 Julia 版本；
- Julia 1.13 测试分支是否继续保留；
- 哪些包已确认兼容，哪些包需要锁定或补丁；
- 数值回归的容差、输入数据和负责人；
- CI 中的版本矩阵与失败通知方式；
- 下一次复核日期，以及触发提前复核的事件；
- 如果新版本失败，如何恢复到旧环境。
如果核心结果一致、包维护状态稳定、CI 和远程 Apple Silicon 验收均通过，可以安排分批升级；如果只有部分成员环境完成验证，双轨通常比一次性切换更稳妥；如果论文复现窗口很近，或者关键包的差异无法解释，暂缓并不意味着技术落后，而是把回退成本控制在可接受范围内。
FAQ
Julia 1.13 发布后，已经运行的科研项目应该马上升级吗？
不建议直接覆盖正式环境。先保存当前 Julia 版本、Project.toml、Manifest.toml、CI 配置和代表性结果，再创建独立测试分支。只有核心包能够解析、关键数值结果通过回归、文档和成员恢复流程也验证完成时，才适合把正式项目切换到 Julia 1.13。
如何系统检查 Julia 1.13 下的科研包兼容性？
先用 Julia 1.13 激活项目环境并执行实例化，再检查直接依赖和间接依赖的解析结果。随后运行包测试、核心脚本和异常路径，重点查看弃用 API、二进制依赖、线程行为以及绘图或文件输出变化。不要只用“能安装、能启动”作为兼容标准。
Julia 新版本怎样验证数值结果没有悄悄改变？
用旧环境生成并保存一组代表性输入、输出、误差指标、收敛曲线和日志，再在 Julia 1.13 中重复运行。对浮点结果设置项目自己的容差，同时单独检查排序、随机种子、缺失值处理、迭代次数和异常信息。若结果差异无法解释，应先双轨运行而不是直接发布。
没有 Mac，怎样测试 Julia 1.13 的 Apple Silicon 环境？
可以使用远程真实 Mac 建立一次隔离验收环境，通过 SSH 或 VNC 安装官方 Julia 二进制，恢复 Project.toml 与 Manifest.toml，然后执行同一组包测试和数值回归。远程环境适合验证 macOS 与 Apple Silicon 路径，但不能替代你对实验室数据、权限和实际外设的测试。
对大多数课题组来说，当前的 Linux 或 Windows 方案仍然适合主力计算，但它们可能缺少原生 macOS、Apple Silicon 二进制路径和图形界面验收条件；临时借用个人 Mac 又会遇到权限、环境污染和成员无法复现的问题。与其为了第一周验证购买一台长期闲置的设备，不如把远程 Mac 作为隔离验收节点，先完成 Julia 1.13 的证据链，再决定是否值得长期投入。SSHMac 的价值在这里不是承诺升级后一定更快，而是让你在不改动正式环境的前提下完成真实 macOS 测试；如果你只需要临时算力或短期兼容性验证，可以先查看 SSHMac 帮助中心，按验收清单确认环境后再决定下一步。