答案是：它们确实不同代，因为“nm” 这个单位已经不表示任何物理长度了。

一、曾经的诚实年代

在 0.35µm 到 28nm 这段时期，工艺节点的名字基本对得上一个真实可测的量——接触栅间距（Contacted Gate Pitch, CGP）或其半值。

注意 28nm 那一行的 Lg 已经是 25nm 了——栅长比节点名还小。也就是说从 28nm 起，”节点名 ≈ 某个特征尺寸”这个等式就已经不成立了，只是当时大家还勉强能找到口径。

二、分水岭：16/14nm 与 FinFET

FinFET 的引入彻底打碎了对应关系。原因很朴素：

• 平面器件时代，性能主要由沟道长度和栅氧厚度决定，微缩路径是一维的——把东西做小。
• FinFET 之后，出现了一组互相耦合的、不可能同时优化的尺寸：鳍宽 $W_{fin}$、鳍高 $H_{fin}$、鳍间距 $FinPitch$、栅极跨过的鳍数量。

于是器件性能变成：

$$ I_{eff} \propto \frac{W_{eff}}{L_g}\cdot \mu_{eff} \cdot C_{ox} \cdot (V_{GS}-V_{TH}) $$

其中 $W_{eff} = N_{fin}\cdot(2H_{fin} + W_{fin})$。

关键就在这个式子里：想让电流上升，不必缩小 $L_g$，只要把 $H_{fin}$ 拉高就行。 高度属于”第三维”，它不占平面面积。厂商第一次拿到了一个不靠微缩也能提升性能的自由度。

从那一天起，节点名就只是”代际标签”了。

三、各家口径对照

把 2020 年后的节点摊开看会更清楚：

几个结论：

1. Intel 的节点号系统性偏保守——Intel 7 的几何尺寸其实贴近别人家的 5nm。这是 Intel 在 2021 年主动改口径（把 10nm 改叫 Intel 7）的结果，属于”重新校准而非缩水”。
2. 三星 3GAE 与台积电 N3 尺寸接近，但结构不同——一个是环绕栅，一个还是 FinFET。
3. 标称数字的差值已经远大于几何尺寸的差值。 从 N5 到 N3，数字降了 40%，CGP 只缩了约 6%。

四、为什么这套话术能持续

因为替换指标的成本太高。

业界试过替代方案：

• Intel 的”每瓦性能代际提升” —— 太抽象，客户听不懂。
• 晶体管密度（MTr/mm²） —— 看似客观，但统计口径可以差出 30%（是否计入 SRAM？算不算 dummy 结构？）。
• IRDS 的”节点后缀体系” —— 学术界认可，市场部不用。

最终胜出的还是数字，因为它可以排序，且天然暗示”越小越好”。营销的语言总是战胜工程的语言。

判断一个节点的真实先进程度，别去看它叫什么，去看三件事：CGP 与金属间距的实际值、器件结构、以及 SRAM bitcell 的面积。

五、一个实用的判断清单

下次再看到”N nm 节点”的宣传，按这个顺序问：

• [ ] SRAM bitcell 面积是多少 mm²？ 这是最难注水、也最能反映真实光刻能力的指标
• [ ] 器件是 FinFET 还是 GAA？ 同尺寸下 GAA 通常有 10~20% 的驱动电流优势
• [ ] 金属层数有多少？ 层数暴涨通常是布线能力跟不上的信号
• [ ] 供电方式：正面还是背面（BSPDN）？ 这是真正的代际差异，比数字大小重要得多

至于那个数字本身——把它当成商标读，而不是当成尺子用。¹

TCAD 的教科书链路通常是 工艺 → 结构 → 器件 → 电路。但实际工作中，前两步之间的那道缝才是最容易出事的地方。

原因在于：刻蚀和沉积是非保形的，而大多数器件仿真器默认你给的是一份”理想几何”。 SEMulator3D 这类基于体素（voxel）的工艺仿真器，价值就在于它老老实实模拟了”材料怎么被一点点拿走/堆上去”。

代价是：它输出的是体素结构，而器件仿真器想要的是连续介质网格。这条接口的质量，几乎决定了整个仿真的可信度。

一、先把工艺配方拆成可仿真的步骤

假设要验证一个 3nm 级别的 GAA 纳米片释放（nanosheet release）工艺。真实配方可能是几十步，先做约束检查：

# process_recipe.yaml —— 精简到只保留影响结构的步骤
steps:
  - id: P01
    type: deposit
    material: SiGe
    thickness_nm: 8
    conformality: 0.95      # 关键：1.0 才是完全保形
  - id: P02
    type: deposit
    material: Si
    thickness_nm: 5
    conformality: 0.98
  - id: P03
    type: repeat             # 交替叠层 x3
    times: 3
    steps: [P01, P02]
  - id: P04
    type: etch
    material: SiGe
    selectivity: {Si: 100, SiGe: 1}   # 对 SiGe 的刻蚀速率比 Si 快 ~100x
    isotropy: 0.8            # 0=完全各向异性, 1=完全各向同性
    over_etch_pct: 15
  - id: P05
    type: anneal
    purpose: SiGe_relaxation
    temp_C: 1050
    time_ms: 2

这几行里藏着三个必须显式建模、否则结果必然失真的参数：

二、从体素到网格：这一步最容易被糊过去

体素结构导出后，网格化时你会遇到一个无法回避的取舍：

# 伪代码：体素 → 器件网格的典型处理
structure = load_voxel("release.structure")

# 方案 A：直接栅格化成六面体网格（快，但界面呈阶梯状）
mesh_a = voxel_to_hex(structure, pitch_nm=0.5)

# 方案 B：表面重建后生成贴体网格（慢，界面光滑）
mesh_b = surface_reconstruct(structure).then(tetrahedral_mesh, min_size_nm=0.3)

# 方案 C：折中——界面附近细化，体区粗化
mesh_c = voxel_to_hex(structure, pitch_nm=1.0)
mesh_c.refine_near(interface, min_size_nm=0.2)

判断标准很具体：如果沟道界面处的网格像楼梯，那么栅氧电场会被系统性算错，最终 $V_{TH}$ 的误差可能达到几十毫伏——这个量级已经足以让你对工艺窗口做出错误结论。

一条经验法则：

界面处的网格尺寸不应大于栅氧厚度的 1/3。对 1nm 等效氧化层，就是 0.33nm 量级——这正是为什么这类仿真的收敛总是很难调。

三、器件仿真与电性提取

拿到贴体网格后，接一个 drifts-diffusion 求解器：

# 用 Sentaurus Device 做 DD 仿真（示意）
sdevice release_mesh.tdr \
  -physics "Hydrodynamic" \
  -bias "Vg 0..1.0 step 0.02, Vd 0.05" \
  -output IdVg.dat, IdVd.dat

从中提出你真正关心的量：

• $V_{TH}$（恒定电流法）：$I_D = 100\text{nA}\times W/L$
• SS（亚阈斜率）：$\text{SS}=\left(\frac{d\log_{10}I_D}{dV_G}\right)^{-1}$，室温理论下限 60 mV/dec
• DIBL：$\frac{V_{TH}(V_D{=}0.05)-V_{TH}(V_D{=}V_{DD})}{\Delta V_D}$
• $I_{on}/I_{off}$ 比

四、真正的目的：回到工艺窗口

电性只是中间产物。仿真链条的价值在于反向给出工艺容差。

做法是扫关键工艺参数的组合，看电性何时越界：

这样你就得到了一条工艺窗口：over-etch ∈ [10%, 15%] 且 isotropy ≤ 0.8。

这才是仿真该交付的东西——不是一个漂亮的 $I_d$-$V_g$ 曲线，而是“哪些工艺参数可以波动，波动到哪里就会失效”。

五、几个踩过的坑

• 别用理想几何代替工艺仿真去”验证”工艺。 如果结构是你手画的，那你验证的是你的画工。
• 选择性刻蚀的 selectivity 值必须来自实测或文献，不能猜。 它是指数级敏感的。
• 体素分辨率不是越高越好。 分辨率翻倍，仿真时间涨 8 倍，而 0.5nm 以下通常在拟合数值噪声。
• 先做二维截面验证，再做三维。 三维不收敛时，你很难判断是物理错了还是网格错了。

工具只是链路的一环。真正决定仿真可信度的，是你有没有认真对待”体素到网格”这一步所引入的误差。

托管平台的静态站部署体验确实好：推代码、自动构建、全球 CDN。但它有三个隐性成本：

1. 域名和流量被绑定——想换平台就要动 DNS。
2. 构建分钟数有额度——博客这种低频更新场景，额度基本用不完，但一旦要跑重构建（比如图片处理），就开始算钱。
3. 调试不透明——重定向、缓存、响应头出问题的时候，你只能猜。

而一台最低配的云服务器（2 核 4G，一年几十块）能承载的静态站，量级远超个人博客的需求。nginx 处理静态文件的能力，是被严重低估的。

一、生成器：三个依赖就够了

核心逻辑其实很短：Markdown → HTML → 写文件。需要的库只有三个：

pip install markdown pygments jinja2

构建脚本的核心就三步：

import markdown, yaml
from jinja2 import Environment, FileSystemLoader
from pathlib import Path

# 1. 读文章 + 解析 frontmatter
def load_post(path):
    raw = path.read_text(encoding="utf-8")
    meta, body = split_frontmatter(raw)      # --- YAML --- 分隔
    md = markdown.Markdown(extensions=["extra", "toc", "codehilite", "tables"])
    return {**meta, "html": md.convert(body), "toc": md.toc}

# 2. 套模板
env = Environment(loader=FileSystemLoader("templates"), autoescape=True)
page = env.get_template("post.html").render(post=load_post(p))

# 3. 写盘
out = Path("dist/posts") / slug / "index.html"
out.parent.mkdir(parents=True, exist_ok=True)
out.write_text(page, encoding="utf-8")

关键设计取舍：输出目录结构用 posts/<slug>/index.html 而不是 posts/<slug>.html。这样 URL 里没有 .html 后缀，将来想换生成器也不用改任何链接。

二、nginx 配置：短，但每一行都有用

server {
    listen      80;
    listen      [::]:80;
    server_name mirror-works.net www.mirror-works.net;

    root  /home/admin/blog/dist;
    index index.html;

    # 无后缀 URL → 找同名目录
    location / {
        try_files $uri $uri/ =404;
    }

    error_page 404 /404.html;

    # 静态资源长缓存：文件名带指纹才敢这么干，
    # 否则改样式用户看不到
    location ~* \.(css|js|svg|png|jpg|webp|woff2)$ {
        expires 7d;
        add_header Cache-Control "public, max-age=604800";
    }

    gzip            on;
    gzip_min_length 512;
    gzip_types      text/plain text/css application/javascript
                    application/json text/xml application/xml image/svg+xml;

    add_header X-Content-Type-Options   nosniff      always;
    add_header X-Frame-Options          SAMEORIGIN   always;
    add_header Referrer-Policy          strict-origin-when-cross-origin always;
}

四个容易踩的点：

• try_files 的顺序必须是 $uri → $uri/，反过来目录会优先，性能更差。
• gzip_types 不会自动包含 text/html——nginx 默认已经为 text/html 开了 gzip，重复写反而会覆盖掉默认值。
• 缓存时间要和构建策略匹配。 如果 CSS 文件名里没有内容哈希（hash），max-age=604800 会让你改完样式刷新十次都看不到效果。稳妥做法是把缓存降到 1 小时，或者加 ?v=<构建时间戳>。
• add_header 在 location 里会覆盖外层同名头，所以要么都写 always，要么都放同一层。

三、HTTPS：交给 Cloudflare

自己签 Let’s Encrypt 证书需要 80/443 都通、还要配 certbot 的自动续期。如果域名本来就托管在 Cloudflare，直接开代理模式（小云朵变橙）更省事：

• 源站只需要暴露 80 端口
• TLS 在边缘终结，证书自动续
• 顺手拿到 DDoS 防护和 CDN 缓存

唯一的注意点：Cloudflare 的 SSL 模式必须从 Flexible 改成 Full 或 Full (strict)，否则源站到边缘这一段是明文，而且会触发重定向循环。

# 验证 HTTPS 与响应头
curl -sI https://mirror-works.net | grep -iE "http/|server|cf-cache-status|strict-transport"

四、自动化：一条 cron 解决发布

写文章和发布彻底解耦——文章就是仓库里的 .md 文件，发布是构建：

# 每 10 分钟检查一次是否有新 commit，有就重建
*/10 * * * * cd /home/admin/blog && \
  git pull -q --ff-only && \
  python3 build.py >> /var/log/blog-build.log 2>&1

如果想要更快的反馈，加个 inotifywait 监听 posts/ 目录，文件一变就重建：

inotifywait -m -e close_write -e moved_to posts/ | while read _ _ file; do
  case "$file" in *.md) python3 build.py ;; esac
done

五、这套方案的真实边界

诚实地讲，它不适合：

• 日均百万 PV 的站点——没有分布式缓存，单机的连接数有上限
• 需要动态能力的场景——评论、搜索服务端渲染、用户系统，这些得另外搭
• 需要全球低延迟——单一地域的服务器在跨洲访问时延迟会明显

但对一个个人技术博客来说，它的性价比高得离谱：没有构建额度、没有平台锁定、没有隐藏账单，出问题时你手上有一整个 shell 可以排查。

可控性不是性能指标，但它是你在半夜三点出问题时唯一在乎的东西。