next/font 本地字体报错,求助
用 next/font/local 加载本地 woff2,本地好好的,build 时报 "Cannot find module" 或者 "Failed to find font"。 排查下来是路径问题。文档说路径相对于当前文件,但实际上是相对于项目根目录(也有人说看版本)。最后统
Next.js、React、TypeScript、前端工程化
本专题收录 Web 开发 方向的文章和社区讨论,重点关注真实工程场景、工具选择、实践路径和风险边界。
页面会持续更新,适合作为学习路线、选型参考和技术复盘入口。
用 next/font/local 加载本地 woff2,本地好好的,build 时报 "Cannot find module" 或者 "Failed to find font"。 排查下来是路径问题。文档说路径相对于当前文件,但实际上是相对于项目根目录(也有人说看版本)。最后统
App Router 的 intercepting routes + parallel routes 做模态框,理论很美,实际上首屏从外层路由跳进模态路由时经常闪一下,或者刷新直接进纯页面。 试过的解法: parallel route 的 default.tsx 必须写,否则 4
Link 默认会 prefetch 链接目标,列表页一屏几十个 link,prefetch 把带宽和 CPU 都吃满了,低端机明显卡。 试了下 <Link prefetch={false} ,列表页首屏反而快了一截。hover 时还是会 prefetch,体验没差太多。 现在的策
基于 App Router 做了一套中后台模板,沉淀了几个比较好用的约定。 每个资源模块是 app/(dashboard)/[resource]/ 下的标准三件套:list / detail / form。 表格列定义抽到 features/[resource]/columns.
'use client' 加在哪个层级,一直没标准答案。加太靠上,整棵子树都变成客户端组件,RSC 的好处没了;加太靠下,文件爆炸。 我现在的原则: 叶子交互组件(按钮、输入框、下拉)单独标 'use client' 。 容器组件尽量保持 server,把 client 组件当
一个内部中后台,纯 SPA,没用 Next.js。Vite + React Query + Tailwind,整套组合用下来非常顺手。 React Query 的缓存策略省了巨多状态管理代码, staleTime 配合 keepPreviousData 做分页表格体验极好。配合
小项目选数据请求库,SWR 和 React Query(TanStack Query)二选一,纠结很久。 简单对比: SWR:体积小,API 简单,够用。 React Query:功能全(mutations、devtools、乐观更新),生态大。 我的结论:< 5 个接口用 SW
项目里两种风格混着用,想统一一下。Server Actions 写起来简洁,但有些场景感觉 API route 更合适。 我的分类: 站内表单、提交后刷新当前页 → Server Actions。 给前端 SDK、移动端、第三方调用 → API route。 需要复杂中间件(限流
在 Server Component 里用 next/headers 的 cookies() 读登录态,本地 dev 正常,部署后偶发读不到。 排查发现是: cookies() 在 Next 15 是 async 了,要 await(已经改)。 跨域 cookie 没带 Same
一年前在新项目里开了全套 strict(strict、noUncheckedIndexedAccess、exactOptionalPropertyTypes),刚开始大家都很痛苦,现在回头看收益巨大。 最大的改变: 重构敢动手了,编译器会兜底。 null 处理变严谨,runtim
几个内部包 + 主应用 + 文档站,迁到 pnpm workspace,整体体验不错。比 npm/yarn workspace 稳很多。 关键配置: 用 workspace: 协议锁内部包版本。 filter 做按需构建,CI 时间砍半。 用 changesets 管版本发布。
听说 TanStack Router 类型安全做得好,拿一个内部工具试了一周。结论是:类型体验确实吊打 Next.js,但生态和心智模型有学习成本。 最爽的是路由参数和 search params 全类型推导,再也不用手写 as string 。 不爽的: 文件路由约定还在演进,