CORS 在 Server Actions 里又坑了我一次
以为 Server Actions 不走 fetch 就没 CORS 问题,结果部署到独立后端域名后,浏览器照样拦。 原因:Actions 本质是 POST 到一个 endpoint,跨域照样受 CORS 约束。需要在 API 层(或反代)显式允许 origin。 特别要注意 N
Next.js、React、TypeScript、前端工程化
本专题收录 Web 开发 方向的文章和社区讨论,重点关注真实工程场景、工具选择、实践路径和风险边界。
页面会持续更新,适合作为学习路线、选型参考和技术复盘入口。
以为 Server Actions 不走 fetch 就没 CORS 问题,结果部署到独立后端域名后,浏览器照样拦。 原因:Actions 本质是 POST 到一个 endpoint,跨域照样受 CORS 约束。需要在 API 层(或反代)显式允许 origin。 特别要注意 N
做一个纯静态文档站,想用 output: 'export' 全量 SSG,build 出 HTML 直接丢 CDN。但担心页面多了 build 顶不住。 试了下 5000 篇文档:build 时间 8 分钟,输出 1.2GB。还能接受。瓶颈在 generateStaticPara
App Router 下做全局 toast,传统的 context + provider 模式套在 root layout 会把整棵树变成 client component,RSC 全废。 现在流行的解法: 用 zustand / jotai 这类非 React Context
App Router 的 loading.tsx 本质是给整个路由包 Suspense,用得好首屏体验起飞,用不好就是 "闪一下骨架屏再闪一下内容"。 踩过的坑: loading.tsx 是静态的,没法根据加载进度切换。 嵌套路由每个 segment 都可以加 loading,层
React 19 终于把 ref 当普通 prop 传了,函数组件不用再 forwardRef 包一层。对组件库作者来说是大好事,API 简洁多了。 但迁移有坑: forwardRef 还能用,但官方标记 deprecated 警告。 既有组件库大改 API,可能要发 major
审计一个慢页面,发现一堆 useMemo 。把 "为优化而优化" 的 memo 删了之后,页面反而快了 30%。 原因:很多 memo 缓存的对象在依赖变化时频繁重建,memo 本身的开销 它省下的渲染。特别是缓存的值只被传给原生 DOM 元素时,完全没必要。 经验法则: 缓存值
接手的项目首屏 JS 1.2MB,扒了下发现一堆组件被无脑标了 'use client' ,整片子树都在客户端渲染。 花了两天做了一次清理: 把不依赖交互的展示组件改回 server。 真正交互的组件下沉到叶子节点。 共享 util 区分 server / client 版本。
需要在路由跳转前做权限校验和埋点,App Router 下没有 pages router 时代的页面级拦截,middleware 又只能做粗粒度的事。 摸索出几种方案: middleware:全局拦截,适合鉴权。 layout 里检查:每层 layout 可以 throw red
做一个不需要 SSR 的小工具,分享一下最精简的 Vite + React + Tailwind 起手配置。 vite.config.ts 里加 Tailwind 插件,CSS 里一行 @import "tailwindcss"; 。不用 postcss、不用 tailwind.
断断续续花了半年,终于把 React 的核心源码啃完了,分享一下方法论,给想读但又怕的同学一点参考。 第一步是不要从第一行开始读,那会直接劝退。正确姿势是带着问题切入,比如"setState 到底是同步还是异步",从这个问题出发去找相关代码。 第二步是善用调试器,在关键函数打断点
因为副业重度用 Next.js,最近花了点时间读它的源码,主要看 App Router 的实现,收获比预期大,分享几点。 第一,Server Components 的设计比我想象的优雅。它把"渲染"拆成了服务端和客户端两部分,中间用一个精巧的协议序列化,理解了这个之后,很多"为什
上周把博客从 WordPress 迁到了 Next.js,整个过程比预想的顺利,分享一下迁移动机和踩过的坑。 迁移动机:WordPress 越来越臃肿,插件之间冲突不断,性能也差;而 Next.js 的静态生成对内容站太合适了,LCP 从 3 秒直接降到 1 秒以内,SEO 友好