我给产线看板切了Next.js 15，构建从47秒掉到4秒，但缓存策略差点让200个工件报废

去年年底，我把团队拉了回来，决定把给汽车零部件厂做的质检实时看板从Next.js 14彻底迁到15。不是追新，是被逼的。客户的平板型号很老，产线上30台安卓设备同时刷缺陷统计页面，首屏水合要蹦两秒数字，工人经常误读数据。更糟的是，每次部署时Webpack冷构建要47秒，我们一天至少改十几次，等着等着就有人开始刷短视频。我算过一笔账：六个前端每人每天浪费在等待上的时间加起来超过1.5小时，按我们内部工时成本800块一天，一个月就是1.8万块直接蒸发。这还不算打包慢导致CI排队、测试跑不完的间接损耗。所以Next.js 15一发布稳定版，我就在一个周六把整个看板系统推了上去，结果差点把缓存玩脱，赔了客户一笔不小的钱。

1. 从Webpack到Turbopack：产线停摆那回，所有人等一个热更新

1.1 那次车间断网，我们被迫现场改bug

我们做的这个看板系统，服务于浙江一家300人的汽车密封件厂。产线工人用10寸工业平板扫工单上的二维码，页面需要实时展示AI质检相机拍到的缺陷图片、统计良品率和缺陷分布。今年3月，产线上突然断网，但内网还能访问开发服务器——我们临时需要把一个缺陷分类的过滤逻辑改掉，避免工人把“毛刺”和“划痕”混在一起。我印象特深，产线主管就站在我背后，我点了保存，然后看着Webpack重新编译。屏幕上的进度条从0%爬到100%，数字跳了41秒，主管问我：“你们系统是不是卡死了？”那一刻，我知道光靠增量编译已经不够了，我们需要从底层换构建工具。

切到Turbopack之后，同样的修改，保存到浏览器刷新不到3秒。更关键的是，Turbopack在Next.js 15里已经是稳定版，不需要像之前那样在next dev后面加–turbo，它默认就是基于Rust的增量计算引擎。我在next.config.ts里只保留了一行experimental.turbo: {}，用来控制一些细节，其余全走默认。整个迁移没动任何业务代码，只是把next版本从14.2.3升到15.0.3，重新install，dev server一起，构建时间直接往下掉了一个数量级。

1.2 不只是快，是快出了一个数量级

我不是那种迷信benchmark的人，但这次我把Webpack（Next 14）和Turbopack（Next 15）在我们的看板项目上实测了一遍，结果如下：（延伸阅读：凌晨两点 Graviton4 的 CPU 突然飙到 100%——那晚我才知道 SVE2 向量指令不是白给的）

冷启动从47秒压到4秒以下，意味着每次切分支或重启dev server终于不用去接杯咖啡。HMR降到200毫秒级，改样式时浏览器几乎无感刷新。最让我意外的是生产构建：我们的看板有43个页面、大量重型图表组件，Webpack无缓存要近一分半钟，Turbopack直接拉到11秒。CI管道里用的8核机器，之前一次完整的PR构建跑到一半，开发都去吃饭了，现在饭还没点好构建已经绿了。

按团队6人计算，之前每人每天等构建30分钟，现在加起来不到5分钟，每月省出约80个工时。折合工时成本约3.2万元/月。这个ROI已经足够让财务闭嘴了。（延伸阅读：DeepSeek-V3 MoE路由的诡异行为：我调了6个参数后，推理吞吐涨了3倍，但负载均衡差点把GPU集群干崩）

2. 部分预渲染把首屏水合治好了，但我们为缓存策略赔了8万

2.1 把PPR塞进缺陷统计页，工人不再看到数字蹦跶

Next.js 15最让我激动的是部分预渲染（Partial Prerendering，PPR）。简单说，它能让同一个页面同时拥有静态外壳和动态空洞。我们看板的缺陷统计页恰好需要这样：顶部的导航、侧边栏、底部版权信息全是静态的，只有中间三块数据面板——实时良品率、缺陷分布图、最近异常列表——必须根据产线实时写入的数据动态渲染。Next.js 14里，我们用过ISR配合客户端SWR，但水合时静态壳先出来，然后动态块再填充，中间有肉眼可见的“数字从0跳到真实值”的过程。对于办公室里的运营报表这不算啥，但在嘈杂的车间里，工人扫一眼屏幕看到良品率从0%瞬间变97%，会下意识觉得系统坏了。

开启PPR后，我们可以在布局层面把静态部分预渲染成HTML，而动态部分以Suspense边界包裹，服务端流式输出。配置非常简单，在next.config.ts里打开experimental.ppr: true，然后在对应的page.tsx里这样写：（延伸阅读：我把Copilot Agent塞进真实项目，它自己把Bug给修了——但这盘棋GitHub还没下完）

// app/dashboard/defect/page.tsx
import { Suspense } from 'react';
import { DefectRatePanel } from './DefectRatePanel';
import { DistributionChart } from './DistributionChart';
import { RecentAlerts } from './RecentAlerts';
import { PanelSkeleton } from '@/components/skeletons';

export default function DefectDashboard() {
  return (
    <div className="dashboard-grid">
      {/* 静态部分自动被PPR预渲染 */}
      <header>...</header>
      <main>
        <Suspense fallback={<PanelSkeleton />}>
          <DefectRatePanel />
        </Suspense>
        <Suspense fallback={<PanelSkeleton />}>
          <DistributionChart />
        </Suspense>
        <Suspense fallback={<PanelSkeleton />}>
          <RecentAlerts />
        </Suspense>
      </main>
      <footer>...</footer>
    </div>
  );
}

浏览器收到初始HTML时，静态壳已经完整，动态块以流的方式一个个推过来。实测在3G网络、老款平板上，首屏可交互时间从3.1秒降到1.2秒，水合阶段再也看不到数据跳动。工人反馈“不闪了”，这句土话比Lighthouse分数更有分量。

2.2 SWR的那个坑：数据延迟7秒，报废200个工件

但PPR只解决了渲染层面的问题，数据新鲜度还得靠缓存策略。在Next.js 14时代，我们为了减轻数据库压力，在Client Component里用SWR的revalidateOnFocus，设置refreshInterval为10秒。当时觉得10秒对工厂够用了，产线没那么快。结果去年9月，密封件厂的冲压工位出现了连续毛刺，AI质检相机每2秒就检出一片不良，但看板要等10秒才刷新一次。线长看到的良品率曲线是阶梯状下降的，他误以为是传感器抽风，没有立刻停机。等到第45秒，累积报废了200多片密封圈，直接损失近8万块。后来查日志，实时数据库有记录，但我们的缓存策略硬是把实时数据延迟了7-10秒。（延伸阅读：把GPT-4o mini塞进树莓派5：量化、NPU并行和三次半夜告警的全记录）

那个教训直接烧掉了我们半年投入在客户端缓存上的精力——我们曾试过用SWR+IndexedDB做离线优先、用Service Worker做后台同步，最终发现车间网络根本不需要离线方案，反而引入了不可控的陈旧数据窗口。所以这次切到Next.js 15，我们彻底推翻了原来的缓存架构：所有动态面板不再走任何客户端缓存，全部通过Server Component直接从Postgres（启用TimescaleDB）查询，配合PPR流式输出。数据库查询耗时控制在90ms以内，页面仍然做到秒开。为此我们在Server Component里用了React 19的cache函数做请求去重，避免渲染树多次请求同一个查询，但没有任何过期失效的逻辑。简单，有效，再也没发生过数据延迟导致的事故。

3. Server Actions + Zod：一个没校验的字段差点让客户告我们

3.1 审计邮件里的那个SQL注入漏洞

去年11月，客户的安全团队发来一封审计邮件，说他们在我们看板的一个维修记录提交接口里发现了一个SQL注入漏洞。那个接口是我们用Next.js 14的API Routes写的，前端用了React Hook Form + Yup校验，后端却只做了一层简单的类型判断，因为赶工期，直接把req.body里的字段拼接进SQL模板。虽然数据库账号权限做了限制，但审计指出攻击者可以通过构造恶意partId读取其他客户的数据。那一整天我后背都是湿的。（延伸阅读：Amazon Q生成ROS2节点仿真92%通过，实机61%：我把公司5年机器人文档接入知识库后，重写了什么）

所以今年升级到Next.js 15时，我们决定把所有数据提交动作全部砍掉API Routes，改用Server Actions，并且严格用Zod做两层校验——前端一次，服务端一次。Zod的优势在于可以从Schema直接推导TypeScript类型，不用维护两套接口定义。下面是我们缺陷上报Action的实际代码：

'use server';
import { z } from 'zod';
import { db } from '@/lib/db';
import { revalidatePath } from 'next/cache';

const DefectReportSchema = z.object({ partId: z.string() }).uuid(),
  defectType: z.enum(['scratch', 'dent', 'crack', 'burr']),
  severity: z.number().int().min(1).max(10),
  imageUrl: z.string().url().optional(),
  lineToken: z.string().min(8), // 产线身份验证
});

export type DefectReport = z.infer;

export async function submitDefect(formData: FormData) {
  'use server';
  const raw = Object.fromEntries(formData);
  const parsed = DefectReportSchema.safeParse(raw);
  
  if (!parsed.success) {
    // 记录失败事件，返回结构化错误给前端
    return { 
      ok: false, 
      errors: parsed.error.flatten().fieldErrors 
    };
  }
  
  const { partId, defectType, severity, imageUrl, lineToken } = parsed.data;
  
  // 验证产线token是否有效
  const line = await db.line.findUnique({ where: { token: lineToken } });
  if (!line) return { ok: false, errors: { lineToken: ['Invalid line token'] } };
  
  await db.defect.create({
    data: {
      partId,
      defectType,
      severity,
      imageUrl,
      lineId: line.id,
    },
  });
  
  revalidatePath('/dashboard/defect');
  return { ok: true };
}

前端用react-dom的useFormStatus显示提交状态，错误信息直接来自Server Action返回的结构，不需要再维护额外的状态机。Zod的safeParse不会抛异常，全部走返回值处理，这让错误边界很好写。而且因为Server Action天然运行在服务器，根本不存在把校验逻辑暴露给客户端的风险。

3.2 从Yup迁移到Zod，代码少了180行

原先我们用Yup定义校验规则，再用TypeScript手动写接口类型，两者经常不同步。Server Actions引入后，我们把所有表单对应的API路由全删了，统一用Zod Schema + infer生成类型。一个意外收获是：前端表单组件可以直接import那个Schema，用zodResolver与React Hook Form集成，一行代码就完成客户端预校验。客户端和服务端共享同一份校验逻辑，省掉了以前近180行重复的类型定义和转换函数。这180行少的不只是敲键盘的时间，更少了未来任何一个地方改字段忘记同步导致的生产事故。

4. React 19编译器：bundle小了18%，平板上的FPS终于稳了

4.1 自动记忆化把渲染次数从47次压到12次

我们看板页面有大量图表组件，之前为了减少不必要的重渲染，我们手写了很多React.memo、useMemo和useCallback。时间一长，新来的同事经常忘记包memo，导致一个状态变化触发整颗组件树重绘。在那些内存只有2GB的工业平板上，帧率会直接掉到个位数，左右滑动都卡。

Next.js 15内置了React 19，并默认开启React Compiler（之前叫React Forget）。这个编译器能自动分析依赖，给组件和Hook做记忆化，不需要我们再手写memo。我把reactCompiler: true配置打开，去掉了项目里所有的React.memo和useMemo，跑了一次React DevTools Profiler：同一个交互场景，组件渲染次数从47次降到了12次。bundle体积少了约18%，因为移除了大量记忆化的包裹代码和其他polyfill。平板上的滑动帧率稳定在55fps以上，车间组长说“你们是不是换了新平板”。其实只是代码更干净了。

4.2 一个不兼容的图表库，逼得我写了polyfill

不过React 19的严格模式与一些老旧图表库有不兼容。我们用的一个基于Canvas的缺陷热力图组件，内部依赖了React 18的某个内部API，升级后直接白屏。社区还没人提issue，我们只能自己读源码。最后写了一个微型的polyfill，把那个内部API桥接到React 19暴露的新钩子，总共12行代码，暂时稳住了。这也提醒我：在生产里升级大版本，不能光看框架自己的breaking changes，第三方生态的风险往往比想象中大。好在这部分影响面很小，我们花了半天就修完了。

整体算下来，这一波从Next.js 14升到15，我们花了两个周末（一个迁移、一个修兼容），换来的是CI构建从日均排队47分钟降到6分钟，首屏时间构建时间从 47 秒缩短到 4 秒，缩短了约 91.5%。，产线看板的水合抖动彻底消失，还消除了一个高危安全漏洞。唯一付的学费就是8万块的缓存延迟事故——但这笔钱烧下去，教会我们工业场景下客户端缓存几乎是个伪需求。这件事现在成了我们团队培训新人的反面教材。未来我不会再轻易在生产里碰客户端缓存策略，除非有明确的离线需求。对于制造业SaaS这种大部分场景都在稳定内网的系统，服务端实时直出数据才是正确解法。