Ethan 发布的文章 - CorePlayers

WebAssembly 在 2025：前端性能优化的终极武器 WebAssembly（Wasm）在 2025 年迎来了 GC（垃圾回收）和组件模型等关键能力，正在从前端的"加速器"升级为"核心基础设施"。越来越多的前端应用将计算密集型任务卸载到 Wasm，实现了显著的性能提升。2025 年 Wasm 生态进展1. Wasm GC 正式落地：支持直接在 Wasm 中使用 JavaScript 对象，解决了 Wasm 与 JS 之间的数据传递瓶颈，性能提升 10-100 倍。2. 组件模型（Component Model）：允许多种语言编写的 Wasm 模块（如 Rust、Go、C++）在同一应用中协作，复用效率大幅提升。3. WASI Preview 2：WebAssembly System Interface 的第二个预览版，为 Wasm 提供了标准化的系统调用接口。前端实战场景图像/视频处理：使用 FFmpeg 编译到 Wasm 进行浏览器端视频转码，处理速度比纯 JS 实现快 20 倍，且避免了上传文件的隐私顾虑。数据可视化：将复杂的数据聚合和统计计算放在 Wasm 中执行，仅将渲染结果传递给 JS 层，避免主线程阻塞。富文本编辑器：ProseMirror 等编辑器使用 Wasm 处理 Markdown 解析和语法高亮，大文档渲染延迟从 500ms 降至 30ms。性能基准测试在一项 SHA-256 哈希计算的测试中，Rust 编译到 Wasm 的执行速度比纯 JS 实现快 5.2 倍，比 asm.js 快 8.7 倍。内存占用方面，Wasm 模块通常比等效的 JS 打包产物少 30-50%。何时使用 Wasm？简单判断标准：如果你的任务涉及大量重复计算、二进制数据处理或需要复用 C/C++/Rust 生态的库，那么 Wasm 是最佳选择。如果是简单的 DOM 操作或网络请求，原生的 JavaScript 仍然是更好的方案。

前后端交互全解析：Axios 封装、跨域方案与 Token 认证机制 前后端交互是现代 Web 应用中最核心的环节之一，涉及请求封装、跨域处理、认证鉴权和数据缓存等多个方面。一个设计良好的 HTTP 交互层可以显著提升开发效率和代码可维护性。本文将系统梳理前后端交互的关键技术点。Axios 企业级封装直接使用 axios 发起请求会导致大量重复代码。一个规范的封装应该覆盖 Token 注入、请求签名、统一错误处理、请求重试和 Token 刷新等能力。// utils/request.ts\nimport axios from 'axios';\nconst service = axios.create();\n\n// 请求拦截器\nservice.interceptors.request.use((config) => `;\n }\n // 时间戳防缓存（GET 请求）\n if (config.method === 'get') ;\n }\n return config;\n});\n\n// 响应拦截器\nservice.interceptors.response.use(\n (response) => = response.data;\n if (code === 200) return data;\n if (code === 401) \n return Promise.reject(new Error(message));\n },\n (error) => \n);跨域问题：从原理到解决方案为什么会有跨域？浏览器的同源策略（Same-Origin Policy）要求协议、域名、端口三者完全一致才允许访问。这是浏览器的安全机制，防止恶意网站窃取数据。需要注意的是，跨域限制是浏览器的行为，服务端之间的请求不受限制。方案一：CORS（后端配置，最主流）// SpringBoot 配置\n@Configuration\npublic class CorsConfig implements WebMvcConfigurer \n}方案二：开发环境代理（Vite 配置，最常用）// vite.config.ts\nserver: \n }\n}方案三：Nginx 反向代理（生产环境首选）前端和后端部署在同一域名下，通过 Nginx 将 /api/ 路径代理到后端服务，彻底避免跨域问题。Token 认证机制深度对比JWT（JSON Web Token）JWT 由三部分组成（Header.Payload.Signature），每部分用 Base64 编码。后端签发后，前端存储在 localStorage 或 cookie 中，每次请求携带在 Authorization 头中。JWT 的核心争议：无状态 vs 不可撤销。JWT 签发后服务端无法主动使其失效——如果你的 access_token 有效期是 2 小时，那么即使你在第 1 分钟就退出登录，攻击者拿到这个 token 后仍可在剩余的 1 小时 59 分内使用它。解决方案：短 access_token + 长 refresh_token（access_token 有效期 15-30 分钟，refresh_token 有效期 7-30 天）或 Token 黑名单（在 Redis 中维护已注销 token 的黑名单）。无感刷新 Token 机制（关键）let isRefreshing = false;\nlet refreshSubscribers = [];\n\nservice.interceptors.response.use(\n (response) => response,\n async (error) => = error;\n if (response?.status !== 401 || config._retry) return Promise.reject(error);\n if (!isRefreshing) = await refreshToken();\n isRefreshing = false;\n refreshSubscribers.forEach(cb => cb(token));\n refreshSubscribers = [];\n return service(config); // 用新 token 重试\n }\n return new Promise((resolve) => `;\n resolve(service(config));\n });\n });\n }\n);前端缓存策略缓存类型存储位置容量过期策略适用场景localStorage浏览器5MB手动清除用户偏好、主题设置sessionStorage浏览器5MB关闭标签页时清除表单草稿、临时状态Cookie浏览器/服务端4KB可设过期时间Token 存储、会话标识IndexedDB浏览器无上限手动管理大量结构化数据、离线应用HTTP 缓存浏览器/代理由响应头控制Cache-Control 头静态资源缓存总结前后端交互的核心设计原则：请求层统一封装，不要散落在各处；认证机制无感刷新，用户登录一次便不再被打断；错误处理统一收敛，不要让每个调用方都写 try-catch；缓存策略分层设计，该缓存的绝不重复请求。

Next.js 15 App Router 最佳实践：路由、缓存与数据获取 Next.js 15 将 Server Components 和 Server Actions 纳入稳定功能，Turbopack Dev 也达到生产可用状态，并重构了缓存策略。本文梳理 2025 年 Next.js 15 App Router 的核心最佳实践。一、Server Components 优先策略app/ 目录下的组件默认都是服务端组件，基本原则是：尽量让父组件（页面）是服务端组件负责取数据，把数据作为 props 传给客户端组件负责交互。// ✅ 推荐：Server Component 直接获取数据 export default async function Page() { const data = await fetch('https://api.example.com/data'); const json = await data.json(); return <div></div>; } // ❌ 避免：不必要的 Client Component 'use client'; export default function Page() { const [data, setData] = useState(null); useEffect(() => { fetch('/api/data').then(r => r.json()).then(setData); }, []); return <div></div>; }二、数据获取策略Next.js 对原生 fetch 做了扩展，支持缓存控制：// ISR 模式：每 24 小时重新验证 fetch(url, }); // SSR 模式：每次请求都重新获取 fetch(url, ); // SSG 模式：永久缓存 fetch(url, );在 Server Component 中推荐使用原生 fetch 而非 axios，因为只有原生 fetch 能享受 Next.js 的缓存扩展能力。axios 在客户端组件中完全可用。三、路由系统要点文件即路由： app/page.tsx → / app/about/page.tsx → /about app/posts/[id]/page.tsx → /posts/:id（动态路由） app/blog/[...slug]/page.tsx → /blog/*（捕获所有路由） Next.js 15 重要变更：params 现在是 Promise 类型，需要使用 await：export default async function PostPage(: > }) { const = await params; // ... }四、缓存策略重构Next.js 15 将缓存从"隐式默认"改为"显式可控"： GET 路由处理程序默认不再缓存 客户端路由缓存默认不再缓存页面组件 开发者需要显式声明缓存策略 这一变更使行为更加可预测，但也要求开发者明确思考每个请求的缓存需求。五、路由守卫实现在项目根目录创建 middleware.ts：import from 'next/server'; import type from 'next/server'; export function middleware(request: NextRequest) { const token = request.cookies.get('token')?.value; if (!token) { return NextResponse.redirect(new URL('/login', request.url)); } }六、并行数据获取利用 Promise.all 避免瀑布式请求：const [user, posts, comments] = await Promise.all([ getUser(params.id), getPosts(params.id), getComments(params.id), ]);

Redis 7.4 新数据结构与高并发缓存策略深度优化 Redis 7.4 作为 2025 年的主力版本，带来了多项对企业级缓存架构有深远影响的新特性。本文将从新数据结构入手，探讨在高并发场景下的缓存策略优化方案。Redis 7.4 新数据结构1. JSON 类型正式版：RedisJSON 从模块进化为内置数据类型。支持 JSONPath 查询和原子级部分更新，性能比存储序列化的 JSON 字符串提升 3-8 倍，尤其在只修改 JSON 对象的一个字段时优势巨大。JSON.SET user:1001 $.name "张三" JSON.GET user:1001 $.address.city JSON.ARRAPPEND user:1001 $.tags '\"redis\"'2. 改进的 Stream 消费者组：支持消费者组间的消息广播模式，一个消息可以被多个组独立消费，适合多系统联动场景。3. 向量搜索（预览）：内置的向量相似度搜索支持 ITEM、L2、COSINE 三种距离度量，为 AI 应用的轻量级语义缓存提供了新的可能。高并发缓存策略优化缓存穿透：使用 Redis 7.4 的 SET 命令新增的 NX 和 EXAT 组合，结合布隆过滤器实现零穿透缓存。对于不存在的数据，缓存空值 60 秒，防止数据库被击穿。缓存雪崩：采用随机过期时间（TTL ± 20% 随机偏移），避免大量 key 同时过期。Redis 7.4 的 EXPIRE 命令支持批量设置和随机偏移，一改之前只能逐个设置的限制。热点缓存：对于那些 QPS 极高的热点 key，使用 Redis Cluster 的哈希标签（Hash Tag）确保热点数据分散在多个节点上，配合客户端本地缓存（如 Caffeine）形成两级缓存架构。

Redis + Caffeine 多级缓存架构与分布式锁实战 缓存是高并发系统的基石。单靠 Redis 已经不足以应对极致性能需求——本地缓存 + 分布式缓存的多级架构才是最优解。本文深入 Redis 核心机制、Caffeine 本地缓存、多级缓存设计和分布式锁实战。Redis 核心数据结构与使用场景 数据结构底层实现典型场景 StringSDS缓存对象、计数器、分布式锁 Hashziplist / hashtable存储对象属性 Listquicklist消息队列、最新列表 Setinset / hashtable标签、共同好友 ZSetziplist / skiplist排行榜、延迟队列 Streamradix tree + listpack消息队列（支持消费组） 缓存穿透、击穿、雪崩：三板斧1. 缓存穿透：查不存在的数据// 布隆过滤器 BF.RESERVE userFilter 0.01 1000000 BF.ADD userFilter "user:999999" // 查询前先判断布隆过滤器：不存在则直接拒绝 // 缓存空值 String value = redis.get(key); if (value == null) { value = db.query(key); if (value == null) { redis.setex(key, 60, "NULL"); // 缓存空值 60 秒 return null; } redis.set(key, value, 300); }2. 缓存击穿：热点 Key 过期public String getWithMutex(String key) { String value = redis.get(key); if (value != null) return value; String lockKey = "lock:" + key; if (redis.setnx(lockKey, "1")) { redis.expire(lockKey, 10); try { value = db.query(key); redis.set(key, value, 300); } finally { redis.del(lockKey); } return value; } else { Thread.sleep(50); return getWithMutex(key); // 递归重试 } }3. 缓存雪崩：大量 Key 同时过期// TTL 加随机偏移 int ttl = 300 + ThreadLocalRandom.current().nextInt(60); // 300~360秒 redis.setex(key, ttl, value); // 多级缓存兜底 public Object get(String key) { Object val = caffeine.get(key); // L1: 本地缓存 if (val != null) return val; val = redis.get(key); // L2: Redis if (val != null) { caffeine.put(key, val); // 回填 L1 return val; } val = db.query(key); // L3: 数据库 redis.set(key, val, ttl + random(60)); // 回填 L2 caffeine.put(key, val); // 回填 L1 return val; }Caffeine 本地缓存配置Cache<String, Object> cache = Caffeine.newBuilder() .maximumSize(10000) // 最大条目数 .expireAfterWrite(5, TimeUnit.MINUTES) .expireAfterAccess(3, TimeUnit.MINUTES) .recordStats() // 开启统计（命中率监控） .build();Redis 分布式锁：Redisson 实战@Autowired private RedissonClient redisson; public void processOrder(String orderId) { RLock lock = redisson.getLock("order:" + orderId); try { // 尝试加锁，最多等待 10 秒，锁 30 秒后自动释放 if (lock.tryLock(10, 30, TimeUnit.SECONDS)) { // 业务逻辑 orderService.process(orderId); } } finally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } } } // Redisson 的 WatchDog 机制：自动续期 // 如果业务还没执行完，WatchDog 每隔 10 秒自动续期到 30 秒Redis 哨兵集群搭建# sentinel.conf sentinel monitor mymaster 192.168.1.10 6379 2 # 2 个哨兵同意才判定下线 sentinel down-after-milliseconds mymaster 5000 # 5 秒无响应判定主观下线 sentinel failover-timeout mymaster 60000 # 故障转移超时 60 秒 sentinel parallel-syncs mymaster 1 # 一次只同步一台新主库总结多级缓存架构的核心思想是"近处快，远处稳"。Caffeine 提供微秒级响应但空间有限，Redis 提供毫秒级响应且可共享，数据库是最后的兜底。分布式锁的关键在于原子性（SETNX）、防死锁（过期时间）、防误删（Lua 脚本校验值）和可重入（Redisson WatchDog）。