相变潜热数值模拟的伪代码设计：焓-孔隙率法与迭代收敛

上周一个做相变储热的朋友发来一段C++代码，说他的仿真程序在处理相变材料充放电过程时，温度曲线在相变点附近总是像抽风一样上下震荡，不管怎么加密时间步长都压不下去。我让他别急着改代码，先把"潜热处理"那一段的算法逻辑用伪代码完整写出来看看。半天后他把伪代码发过来，问题一眼就看明白了：液相分数的更新把当前时刻温度和上一时刻温度混在一起用，所谓的内部迭代根本没有真正迭代起来。这已经不是第一次有人栽在这种问题上——相变潜热处理本身就是一个强非线性、多物理场耦合的数值问题，物理逻辑一旦在代码和公式之间"翻译"错了，后面所有的调参都是在浪费时间。

这篇文章就从那次debug聊起。我会把"伪代码示意相变潜热处理"这件事拆开讲透：相变潜热的物理本质到底是什么、焓-孔隙率法这套主流数值框架在计算层面经历了哪几步、如何在纸面上提前规避数值振荡，以及伪代码作为一种算法设计语言，具体该怎么组织才不至于把读者绕晕。不管你是做CFD仿真的工程师、学传热学的研究生，还是刚接触数值编程、想搞懂"算法的伪代码怎么写"的开发者，这篇文章都可以直接当参考。

1. 为什么相变潜热问题要先写伪代码——一次debug给我的教训

先复盘一下朋友那个案例。他的程序本身写得很规整，类封装、参数列表、注释都不算差，但问题恰恰出在"代码太具体"上：几百行的循环里夹杂着物理更新、边界处理、数值求解和输出逻辑，时间步进的外循环和相变源项的内迭代搅在一起，我很难一眼看出他到底用的是哪种时间离散、哪种迭代策略。后来让他把伪代码写出来，压缩到三十行左右，所有问题立刻暴露了——f_l（液相分数）在第4步用新温度更新，但第2步组装系数矩阵时用的还是更新前的旧值，中间没有任何迭代路径能把这个滞后的信息补回来。

这就是伪代码的第一个价值：它强迫你只保留算法的骨架，砍掉语言层面的枝叶。当你只写T_new ← TDMA(A, b)而不是去纠结std::vector的迭代器怎么传参时，判断一个算法是否逻辑自洽会容易得多。尤其对相变潜热这种问题，它不像普通的稳态导热，写个线性方程求解器就能完事；相变过程自带移动边界、潜热释放和强源项非线性，每一步时间推进里至少嵌套了三层物理过程：

• 温度场决定液相分数（相变是否发生、发生多少）；
• 液相分数反过来通过源项影响温度场；
• 潜热释放又会改变温度场的分布，进而改变下一时刻的液相分数。

这种相互耦合如果不用伪代码把"谁先算、谁后算、循环几层、收敛判断用什么量"的规定清楚，直接在真实代码里调，很容易陷入"改一个参数、另一个地方崩掉"的泥潭。伪代码相当于把算法从"机器要执行的指令序列"翻译回"人脑能推演的物理-数学逻辑"，在动手编码之前先拿它在纸面上做一次推演。

还有一个常被忽略的好处：伪代码是团队评审的最佳载体。真实代码里有大量的工程细节，别人很难在半小时内抓住核心算法；但一份写得好的伪代码，组里任何懂物理的人都能直接review。我身边很多做储能仿真和金属凝固模拟的团队，现在都要求论文复现或模块开发之前必须提交一份伪代码评审稿，目的就是让算法逻辑在投入大量编码时间之前，先经过一轮"物理正确性"检查。

所以这里我给出的建议是：对于相变潜热处理这类涉及多场耦合的问题，伪代码不是给老师交作业用的形式主义，而是一个真正的设计工具。下文所有内容都会围绕"如何设计一份能落地的相变潜热处理伪代码"展开。

2. 相变潜热的物理与数值本质：不搞懂这两点，伪代码无从下手

如果说伪代码是表达手段，那么物理本质就是你要表达的内容。如果对相变过程中的能量方程理解不到位，写出来的伪代码再漂亮也是空中楼阁。

2.1 潜热到底"潜"在哪里

先做一个生活类比的铺垫。烧一壶水，你会发现一个非常有意思的现象：水从20℃加热到100℃只需要几分钟，但从100℃开始沸腾到整壶水烧干，却要花十几分钟，而且整个沸腾阶段温度一直钉在100℃不动。你持续输入的热量去哪儿了？答案是它们被水分子"吸收"去完成液—气相变，这个过程中温度不升高，能量以分子间势能的形式储存起来，这就是潜热（Latent Heat）。固液相变同理：冰在0℃融化时，温度也不会上升，直到所有冰都变成水，温度才会继续往上走。

在数值模拟里，这个问题比"温度不变"要复杂得多。对于一个纯物质，相变发生在单一温度点，固液界面是数学上的一个间断面；但对于合金、石蜡、盐类水合物等工程常用的相变材料，相变发生在一个温度区间（固相线温度 T_s 到液相线温度 T_l 之间），在这个区间内材料处于"糊状区"（mushy zone），固体骨架和液体共存。数值模拟必须回答三个问题：每个网格现在处于什么相态？相变过程中能量怎么分配？相变前沿在哪、以什么速度移动？

这三个问题在数学上被归结为著名的Stefan问题——一个带移动边界的热传导方程。移动边界的麻烦之处在于它不是一个固定的几何位置，而是由温度场本身决定的一条等温线（或等温面），并且边界上需要满足能量守恒：界面吸收/释放的潜热等于两侧热流之差。如果直接追踪这条界面，网格会不断变形或重构，计算量非常大，而且在三维复杂几何里几乎不可行。

2.2 等效热容法的局限

早期工程上常用等效热容法（Apparent Heat Capacity Method）回避移动边界追踪。思路很简单：既然相变在温度区间 T_s~T_l 内发生，那我就在这个区间内把比热容人为放大，把潜热"摊到"这个温度区间里：

c_eff = c_p + L / (T_l - T_s)（当 T_s < T < T_l）

这样方程形式上还是一个普通的导热方程，只是物性参数分区赋值。这个方法实现简单，但有两个致命弱点。第一，它与网格分辨率强相关：如果网格没有有效解析相变温度区间的空间跨度，潜热释放就会被"平均"到一个过大的体积里，导致相变平台被抹平。第二，它对时间步长敏感：如果单个时间步内温度步进跳过了整个相变区间，潜热甚至可能被完全漏掉。换句话说，等效热容法把"移动界面"这个尖锐问题模糊化了，代价是必须用极细的网格和极小的步长去补，得不偿失。

2.3 焓-孔隙率法：把相变问题从"追踪界面"降维成"更新标量场"

现在数值模拟的主流选择是焓-孔隙率法（Enthalpy-Porosity Method），商用软件Fluent的solidification/melting模型用的就是它。它的核心思想是：不追踪界面，而是用一个连续变化的标量场——液相分数 f_l——来描述每个网格的相态。f_l = 0 表示纯固态，f_l = 1 表示纯液态，0到1之间就是糊状区。

用焓形式写出能量方程：

∂(ρh)/∂t + ∇·(ρ v h) = ∇·(k∇T)

其中比焓被拆成显热和潜热两部分：

h = ∫c_p dT + f_l · L（L为相变潜热）

这样相变引起的能量变化被隐含在f_l·L这一项里，界面的位置可以事后通过等值线（比如 f_l = 0.5）提取，不再需要动网格。而为了处理糊状区里液态金属或液体的流动，焓-孔隙率法还会在动量方程里加一个Darcy源项，把糊状区当成一种多孔介质：液相分数越小，渗透率越低，流动阻力越大。当 f_l 趋于0时，源项趋于无穷大，固体区域的速度自动被"钉死"。

这套方法的本质是把一个移动边界问题转化成一个场方程问题，代价是需要额外的内迭代来处理液相分数和温度之间的强耦合。而这正是伪代码最该表达清楚的地方——一次时间步内，变量的更新顺序和迭代路径决定了程序是否稳定、是否收敛。

3. 焓-孔隙率法的完整骨架：用两段伪代码说清一次时间步长内做了什么

有了前面的物理基础，可以开始写伪代码了。我习惯把伪代码分成两层：顶层框架负责表达"程序有几个大步骤、循环怎么套"，核心段落负责表达"每个步骤里的数学运算和变量更新规则"。先看顶层骨架。

3.1 顶层时间推进框架

text复制PROCEDURE MeltingSimulation
输入：网格数量 Nx，空间步长 Δx，时间步长 Δt，总时长 t_end，
    材料属性 ρ, c_p, k, L, T_solidus, T_liquidus，
    初始温度场 T_init，边界条件

// ---------- 初始化 ----------
T[1..Nx] ← T_init
f_l[1..Nx] ← InitialFraction(T)          // 根据初始温度确定每个网格的液相分数
H[1..Nx] ← c_p * T[1..Nx] + L * f_l[1..Nx]   // 焓场初值
t ← 0
n ← 0

// ---------- 时间推进 ----------
WHILE t < t_end DO
    n ← n + 1
    t ← t + Δt
    T_old ← T
    T ← T_old                            // 内部迭代的初值

    // 内部迭代：处理相变源项的非线性
    innerIter ← 0
    resid ← ∞

    WHILE resid > tol AND innerIter < maxInnerIter DO
        innerIter ← innerIter + 1

        // (1) 相变源项的线性化组装
        // (2) 离散能量方程并求解，得到 T_new
        // (3) 用 T_new 更新液相分数 f_l（带松弛和截断）
        // (4) 更新焓场 H
        // (5) 计算残差 resid

        T ← T_new
    ENDWHILE

    // 记录当前时刻的温度、液相分数、界面位置等统计量
    OUTPUT t, T, f_l, H
ENDWHILE
ENDPROCEDURE

这份顶层伪代码真正想强调的只有两个点。第一，时间步进的外循环和相变非线性迭代的内循环是分开的，绝不能用时间步进的次数兼任非线性迭代的次数。第二，初始化阶段必须给 f_l 和 H 都赋好初值，因为后面的迭代依赖的是物理场之间的相互牵引，初始场给不对，程序会在第一时刻就发散。

很多初学者会在这里犯一个隐蔽的错：外部 WHILE t < t_end 循环里只调一次"求解能量方程"就跑到下一时刻。这对没有相变的纯导热问题没毛病，但相变问题里 T 和 f_l 的耦合是强非线性的，一个时刻只更新一次，温度场还没"感知"到潜热的影响就进入了下一个时间步，自然会出现相变点附近的震荡。所以我在这份伪代码里明确写了内循环 WHILE resid > tol AND innerIter < maxInnerIter，就是要让每个时间步内部的物理耦合充分"消化"掉再往前走。

3.2 核心迭代段的伪代码：从线性化组装到残差检验

再往下一层，把内部循环的每一步具体化：

text复制// ====== 核心迭代段 ======

// (1) 相变源项线性化：S = S_C + S_P * T
FOR i = 1 TO Nx
    // Darcy源项（动量方程）对应的等效热源；
    // 当 f_l→0 时S_P绝对值非常大，相当于钉住固体区
    S_P[i] ← -A_mush * (1 - f_l[i])^2 / (f_l[i]^3 + eps)
    S_C[i] ← -S_P[i] * T_ref
ENDFOR

// (2) 组装离散系数矩阵（一维隐式格式）
FOR i = 1 TO Nx
    aE[i] ← k / Δx^2
    aW[i] ← k / Δx^2
    aP[i] ← ρ * c_p / Δt + aE[i] + aW[i] - S_P[i]
    b[i]  ← ρ * c_p / Δt * T_old[i] + S_C[i]
ENDFOR
// 边界节点按第一/第二/第三类边界条件单独修正aP和b

// (3) 用TDMA解三对角方程组 A*T = b
T_new ← TDMA(aW, aP, aE, b)

// (4) 更新液相分数：带松弛，避免振荡
FOR i = 1 TO Nx
    f_star[i] ← EquilibriumFraction(T_new[i])
    f_l[i] ← f_l[i] + relax * (f_star[i] - f_l[i])
    // 截断到物理范围
    IF f_l[i] < 0 THEN f_l[i] ← 0
    IF f_l[i] > 1 THEN f_l[i] ← 1
ENDFOR

// (5) 更新焓场
FOR i = 1 TO Nx
    H[i] ← c_p * T_new[i] + L * f_l[i]
ENDFOR

// (6) 收敛残差
resid ← 0
FOR i = 1 TO Nx
    resid ← max(resid, |T_new[i] - T[i]|)
ENDFOR

配合一个辅助函数 EquilibriumFraction：

text复制FUNCTION EquilibriumFraction(T)
    IF T <= T_solidus THEN
        RETURN 0
    ELIF T >= T_liquidus THEN
        RETURN 1
    ELSE
        RETURN (T - T_solidus) / (T_liquidus - T_solidus)
    ENDIF
ENDFUNCTION

这里有几个值得展开的地方。TDMA（三对角矩阵算法）是求解一维隐式离散方程最常用的直接解法，计算量O(N)，一维问题里基本是标配；如果你在二维四边形网格或三维六面体网格上做，矩阵不再三对角，这时就要换成共轭梯度法或多重网格，但伪代码层面只需要写求解线性方程组这一步，具体求解策略属于"实现细节"，可以留到真实代码里再决定。

另外一个细节是源项线性化里的正负号。Patankar在《Numerical Heat Transfer and Fluid Flow》里强调过一个原则：源项线性化成 S = S_C + S_P * T 后，S_P 必须非正（≤0），否则会破坏系数矩阵的对角占优性，导致迭代发散。在这份伪代码里我写的 S_P[i] ← -A_mush * (1-f_l[i])^2 / (f_l[i]^3 + eps)，就是一个天然非正的构造：如果当前网格还是液体（f_l接近1），分子趋近0，源项几乎不起作用；如果是固液混合区（f_l在0到1之间），源项会把该区域的温度"拉"向参考温度，模拟糊状区的相变缓冲；如果已经凝固（f_l=0），源项绝对值巨大，温度被牢牢钉住。eps 通常取一个极小值如 1e-3，目的是防止分母为零。

4. 液相分数更新里的松弛、截断与收敛判据：最容易崩在细节上

顶层框架和核心伪代码写完了，程序跑起来之后，真正决定"是稳定收敛还是震荡发散"的，往往是那些看起来不起眼的细节。这一节我把液相分数更新和收敛判断单独拎出来，因为这是我实战中踩坑最多的地方。

4.1 为什么液相分数更新必须加松弛

如果你把核心迭代段的第(4)步写成直接赋值 f_l[i] ← EquilibriumFraction(T_new[i])，在大多数情况下程序会振荡甚至发散。原因是：T 和 f_l 是相互强耦合的变量，如果直接用新算出来的温度全覆盖旧的液相分数，相当于给系统灌入了一个"过激的修正"，下一轮迭代的温度场又会因为这个过度修正产生反向的大幅调整，形成振荡。这一点在相变区间（糊状区）内尤其明显，因为在那个区间内 f_l 对 T 的导数最大，一个很小的温度扰动就能引起很大的液相分数变化。

松弛更新的本质是"只往前走一小步"：

f_l_new = f_l_old + relax * (f_star - f_l_old)

relax 的取值没有万能标准，我个人的经验是 0.1到0.3之间比较稳。0.3以上的松弛因子在一些材料体系里就会开始出现可观测的迭代残差震荡，0.1以下虽然稳但收敛慢。一般做法是先取0.2，跑通之后逐步增大，看到残差曲线出现等幅振荡或上升再往回退。注意这个经验值只适合液相分数的松弛；如果能量方程本身还用了欠松弛（比如压力速度耦合里的PISO/PIMPLE），那两套松弛因子不要混用同一套经验，要分别标定。

4.2 截断到[0,1]是物理约束，不是数值技巧

细心的读者可能会问：EquilibriumFraction 函数在 T < T_solidus 时返回0，T > T_liquidus 时返回1，那理论上松弛更新后 f_l 应该也在[0,1]内，为什么还要额外加 IF f_l < 0 THEN f_l ← 0 这类截断？

答案是：松弛更新会破坏解析约束。假设某个网格上一时刻的 f_l 是0.95（接近全液），这一时刻计算出的 T_new 异常低，导致 f_star 是0，那么松弛更新计算出的 f_l 可能是0.7，这没问题；但如果上一时刻的 f_l 是0.02（接近全固），这一时刻 T_new 远低于固相线，f_star = 0，松弛更新算出的 f_l 就可能是负值。负的液相分数在物理上没有意义，更糟糕的是它会在下一轮迭代进入源项计算式的分母 f_l^3 + eps，如果是负的且绝对值略大于 eps，源项符号就会反转，数值上瞬间爆炸。

所以截断这行代码不是锦上添花，而是一个防机动性事故的保险栓。我在多个工程案例里验证过：只要把 f_l 的上下限截断加上，源项振荡的很多"灵异现象"会直接消失。

4.3 残差检验选什么量：温度残差 vs 焓残差

核心迭代段的第(6)步我用了温度残差 max|T_new - T|。这个选择在多数情况下够用，因为它直观、量纲清晰、容易设阈值（比如 1e-6 K 或者 1e-8 相对残差）。但如果你发现温度残差已经收敛到很小，而后续统计的储热量仍然不准，那说明温度残差不是这个问题的敏感指标。

我遇到过这种情况：温度场已经很接近收敛解，但液相分数的残差还有波动，因为温度在相变区间内的微小变化对应着液相分数的明显改变，而液相的分布才是系统储热量的主导因素。处理办法有两种：一是把残差定义改成同时监控温度和液相分数：

resid = max( |T_new - T| / T_scale, |f_l_new - f_l| )

二是直接监控焓场残差，因为焓是温度和液相分数的线性组合（H = c_p*T + L*f_l），焓的残差天然兼顾两者。我个人倾向于焓残差，尤其是储能系统的总储热量保守性校验时，焓场残差比温度残差更有工程意义。下面给一个简单的残差方案对照表：

5. 伪代码写作规范：让相变逻辑在纸上就能被审出错误

前面花了大量篇幅讲物理和数值，现在回到这个项目的另一个核心命题：伪代码到底怎么写才合格。还是说回那个"高温相变储热"的项目——伪代码写完之后，他组里的一个师兄不到十分钟就指出了源项线性化的符号问题，这在真实代码里可能要排查好几天。伪代码的价值在这个场景下体现得淋漓尽致。

5.1 伪代码的语法约定

很多初学者把伪代码写成了"长得像Python但不是Python"的半吊子代码，这是最尴尬的状态：它既没有自然语言的可读性，又保留着编程语言的语法噪音。我推荐的伪代码不是这个样子，它有意识地使用少量约定，保证任何语言背景的人都能无障碍阅读：

前4条的本质都是"用最直觉的符号替代编程语言的语法噪音"，让读者不需要懂任何语言就能理解流程。第6条尤其重要——伪代码不是可执行代码，遇到短时间写不清楚的复杂操作，直接用自然语言描述是正确的选择，比如"用多维牛顿法求解非线性方程组"这句话写在伪代码里完全合格，它不需要展开成具体的迭代格式。

5.2 哪些该写进伪代码，哪些该留在真实代码

这是我这几年总结出来的一个关键判断标准：伪代码只写"算法必须完成的事"，不写"怎么做这件事的实现细节"。具体到相变潜热处理：

应该写进伪代码的：

• 控制流（循环、判断、迭代关系）
• 变量的物理含义和更新顺序
• 数值方法的抽象（求解线性方程组、计算残差）
• 物理约束（液相分数截断、温度范围）
• 算法层面的参数（松弛因子、收敛阈值）

应该留在真实代码的：

• 数组下标的偏移（C++从0开始，Fortran默认从1开始）
• 具体线性方程求解库的选择（Eigen、PETSc、自定义TDMA）
• 单位换算和物性参数的数值
• 并行通信细节（MPI/OpenMP）
• 输入输出文件格式

一个反面的例子是，我见过有人把伪代码写成这样：

text复制for(int i = 0; i < Nx; i++) {
    a[i] = (k[i+1] - k[i-1]) / (dx * 2);
}

这已经是一段"伪装的C++"，而不是伪代码。它的问题在于：i-1和i+1属于网格拓扑细节，k的梯度计算属于实现细节，这些信息对物理逻辑的理解没有帮助，反而遮挡了"能量方程的空间离散采用中心差分"这个真正重要的算法决策。正确的伪代码应该写成：

text复制FOR 每个内部节点 i
    // 中心差分近似温度梯度
    flux[i] ← (k(i+1/2) * (T[i+1] - T[i]) - k(i-1/2) * (T[i] - T[i-1])) / Δx
ENDFOR

5.3 一个好伪代码的判断标准

最后给一个实用判断方法：把伪代码发给一个不熟悉你代码、但懂这个领域物理的同事，如果他能在半小时内指出算法层面的问题，或者能照着伪代码独立实现出一版正确的程序，这份伪代码就是合格的。反过来，如果对方需要反复问你"这里 aP 是什么""为什么这一步要放在这个循环里"，那说明伪代码的抽象层次或信息量还需要调整。

我在实际项目中养成的习惯是，伪代码写完先放一个晚上，第二天拿起来再读一遍，凡是需要回忆才能想起来的"当然"和"显然"，一律补进注释里。因为代码写完后，真实代码会不断演进，但伪代码作为"算法的最初设计蓝图"，会陪伴整个开发周期和后期维护，值得花时间打磨。

6. 从伪代码到真实代码的迁移：单位、求解器与验证算例

伪代码终归是设计图，最终要落到真实代码里。这一步看着简单，但我在迁移过程中踩过的坑一点也不比设计算法时少。这节讲几个高频问题。

6.1 单位制与数组边界：两个最容易被忽略的"环境变量"

首先是单位制。伪代码里写 ρ, c_p, k, L 一目了然，但真实代码里这些参数来自不同的数据源，可能是混合单位：ρ 用 kg/m³、c_p 用 J/(kg·K)、k 用 W/(m·K)，这通常没问题；但有些材料手册里的潜热 L 用的是 kJ/kg，比热容却是 J/(kg·K)，少一个数量级换算，相变平台会凭空偏移几百度。我的建议是真实代码里不要用原始输入，先做一个PhysProps结构体，在初始化阶段统一转换成SI基础单位，代码里只用标准量纲。伪代码阶段就要在注释里写清楚"所有输入量统一使用SI单位"，否则这份伪代码在跨团队协作时会成为事故温床。

其次是数组边界。Fortran默认下标从1开始，C/C++默认从0开始，Python也是0；伪代码里的T[1..Nx]写得很清楚，但真实代码里如果因为边界处理出现T[-1]越界访问，程序可能不会立刻报错，而是静默地修改了相邻内存，制造出极其隐蔽的数值错误。所以迁移的第一步，是确定你的语言和数据结构从0开始还是从1开始，并在所有循环边界上做一次显式的自查。

6.2 隐式求解的线性方程组：选对工具，事半功倍

伪代码第(2)步写的是组装三对角矩阵并用TDMA求解，这个在一维空间里是效率最优的；如果项目跑到二维或三维，矩阵变成稀疏带状矩阵，TDMA就用不了了。迁移时你会面临几个选择：

• 手写TDMA排程：适合一维教学代码和快速验证，代码量30行左右。
• 使用现成线性代数库（如Eigen、PETSc、SciPy的linalg.solve_banded）：适合科研代码，调库比自己造轮子快得多，而且数值稳定性有保障。
• 迭代求解器（共轭梯度法、BiCGStab、代数多重网格）：适合大规模工程问题，但对预处理器的选择很敏感，需要做收敛性测试。

我的经验是：伪代码跑通之后，先用一个小规模网格（比如Nx=100）直接验证算法逻辑，这时候用最简单的TDMA手写版本就够了；等确认物理逻辑没有问题，再根据目标问题规模切换求解器。这里千万不要一上来就上大规模并行框架，否则你会同时面对"物理逻辑错误"和"并行通信错误"两类问题，调试难度成倍上升。

6.3 用一维熔化算例验证：解析解是最好的照妖镜

相变数值代码写完之后，怎么确认它是对的？我有两个层次的验证方法。

第一层是解析解对照。如果相变材料是纯物质（相变温度是单个值而不是区间），一维半无限大区域熔化过程存在Neumann解析解，熔融前沿位置随时间的平方根移动：x_front(t) = 2λ√(αt)，其中λ由界面能量平衡方程隐式给出。你可以初始化一个一维计算域，左边界给一个恒温（高于熔点），右边界保持绝热或固定温度，跑一段时间后对比数值模拟的熔融前沿位置和解析解。如果误差在几个百分点以内，说明潜热处理的核心逻辑基本正确。

第二层是能量守恒全局校验。记录整个计算域的总能量变化（显热+潜热）和通过边界流入的总热量，两者之差应该为零（在数值离散误差范围内）。如果能量不守恒，问题几乎必然出在源项线性化或者焓场更新公式上，而不是时间步长或网格的问题。我在做焓-孔隙率法调试时，能量守恒校验帮我在几分钟内定位了液相分数截断位置写错的bug，比盯着云图猜原因快了十倍不止。

如果这两个测试通过了，这份伪代码对应的真实代码才算"真正能用的正确代码"。后续再去做界面位置追踪的可视化、多相流耦合、复合材料等效物性等进阶功能，都是在已验证的骨架上添砖加瓦了。

我现在养成的习惯是，任何一个相变相关的模块，不管最后用什么语言、什么库实现，都先留一份伪代码在项目文档里。它既是设计记录，也是调试时的索引，更是换人接手时最快能建立全局观的那张地图。伪代码示意相变潜热处理这件事，表面上看只是"把逻辑写清楚"，实际上逼着你在动手写代码之前，把物理本质、数值方法和实现细节三者彻底理顺。这是我踩过无数次坑之后，最想分享给同行的经验。