Now vibe coding, so learning hammer FE ?
《一次被低估的重构如何让内存暴降90%——TanStack_Table_V9内存优化揭秘》
标签：#前端 #TanStackTable #性能优化 #JavaScript #内存管理
总结：
TanStack_Table_V9通过将行、列、单元格和表头对象的方法从实例属性迁移到共享原型上，实现了大型表格场景下最高达90%的内存节省。这一改动让V9能处理1000-1600万行数据（V8仅约150万行即达4GB内存上限），同时保持了动态特性组合的能力，仅带来解构方法调用这一处Breaking_Change。
文章要点：
1. 数据亮眼：处理100万行×8列时，V9比V8节省超2.4GB内存，最高降幅达90.5%，表格承载能力从约150万行跃升至1000-1600万行
2. 核心手法：用
3. 不用类的智慧：因为TanStack_Table的特性是动态组合的（按需注册排序、筛选、分页等），单继承的Class难以优雅表达"条件式多重继承"，手动原型模式更灵活
4. 唯一代价：方法不能再解构调用（如
5. 通用启示：任何需要大规模创建相似对象的库或应用，都可以借鉴这种"共享原型+实例数据分离"的模式来优化内存
URL：https://tanstack.com/blog/tanstack-table-v9-memory-performance
标签：#前端 #TanStackTable #性能优化 #JavaScript #内存管理
总结：
TanStack_Table_V9通过将行、列、单元格和表头对象的方法从实例属性迁移到共享原型上，实现了大型表格场景下最高达90%的内存节省。这一改动让V9能处理1000-1600万行数据（V8仅约150万行即达4GB内存上限），同时保持了动态特性组合的能力，仅带来解构方法调用这一处Breaking_Change。
文章要点：
1. 数据亮眼：处理100万行×8列时，V9比V8节省超2.4GB内存，最高降幅达90.5%，表格承载能力从约150万行跃升至1000-1600万行
2. 核心手法：用
Object.create创建共享原型对象，将方法统一挂载到原型上，实例只保留独有数据，彻底消灭百万级重复函数对象及其闭包作用域3. 不用类的智慧：因为TanStack_Table的特性是动态组合的（按需注册排序、筛选、分页等），单继承的Class难以优雅表达"条件式多重继承"，手动原型模式更灵活
4. 唯一代价：方法不能再解构调用（如
const {getValue} = row会丢失this），且Object.keys/{...row}浅拷贝不会包含方法，但直接调用row.getValue()一切正常5. 通用启示：任何需要大规模创建相似对象的库或应用，都可以借鉴这种"共享原型+实例数据分离"的模式来优化内存
URL：https://tanstack.com/blog/tanstack-table-v9-memory-performance
Tanstack
How an Underrated Refactor Saved 90% Memory Usage | TanStack Blog
TanStack Table V9 can use dramatically less memory than Table V8 in large tables because row, column, cell, and header APIs now live on shared prototypes instead of every object instance.
《Playwright Fixtures 的"魔法"实现原理》
标签：#测试 #Playwright #JavaScript #API设计 #源码分析
总结：
作者深入剖析 Playwright 的 Fixtures API 如何通过
文章要点：
1. 懒加载是核心卖点**：Playwright 的 fixtures 按需初始化，不用就不创建，能节省测试执行时间；但传统 Proxy/getter 方案会导致异步 fixture 需要 `await`，破坏 API 体验
2. "偷看"函数参数是关键**：Playwright 在不调用测试函数的情况下，就能知道它需要哪些 fixture，这解决了"鸡生蛋"难题——要知道用哪些 fixture 才能准备它们，但准备前又不能运行测试
3. **`Function.prototype.toString()
4. **解析逻辑相当 robust**：源码展示了
5. **压缩工具不会破坏它**：实测 Terser 和 esbuild 的 minify 只会把参数名缩短（如
6. **魔法有代价**：函数组合（如 `noThrow(fn)
7. **作者态度很诚实**：认可 Playwright 团队的选择非常适合测试框架场景，但坦言这种魔法比个人期望的多了一点，想不出其他库有同样充分的理由采用此方案
URL：
https://ivakin.dev/blog/how-playwright-fixtures-work
标签：#测试 #Playwright #JavaScript #API设计 #源码分析
总结：
作者深入剖析 Playwright 的 Fixtures API 如何通过
Function.prototype.toString() 在测试运行前"偷看"函数参数，实现按需懒加载。文章揭示了这一巧妙但略带"魔法"的设计：Playwright 强制要求测试函数使用对象解构语法（如 `async ({ page }) =>`），然后通过正则解析源码字符串提取 fixture 名称，从而只初始化测试真正需要的依赖。作者还验证了该方案对不同函数类型、压缩工具（Terser/esbuild）的兼容性，并坦诚讨论了其"神奇感"与潜在局限性。文章要点：
1. 懒加载是核心卖点**：Playwright 的 fixtures 按需初始化，不用就不创建，能节省测试执行时间；但传统 Proxy/getter 方案会导致异步 fixture 需要 `await`，破坏 API 体验
2. "偷看"函数参数是关键**：Playwright 在不调用测试函数的情况下，就能知道它需要哪些 fixture，这解决了"鸡生蛋"难题——要知道用哪些 fixture 才能准备它们，但准备前又不能运行测试
3. **`Function.prototype.toString()
是秘密武器**：Playwright 把测试函数转成字符串，用正则提取解构参数，因此强制要求 `async ({ page }) => 这种写法，否则直接抛错"First argument must use the object destructuring pattern"4. **解析逻辑相当 robust**：源码展示了
innerFixtureParameterNames 的实现，能正确处理普通函数、async 函数、生成器函数、箭头函数等多种声明方式，还能处理带默认值的复杂解构5. **压缩工具不会破坏它**：实测 Terser 和 esbuild 的 minify 只会把参数名缩短（如
foo → `o`），不会改解构语法，所以 Playwright 的正则解析依然能工作6. **魔法有代价**：函数组合（如 `noThrow(fn)
包装后传入）会失效，因为 `toString() 拿到的是包装函数的源码而非原始函数；这种"黑魔法"虽然 DX 很好，但违反了"最小惊讶原则"7. **作者态度很诚实**：认可 Playwright 团队的选择非常适合测试框架场景，但坦言这种魔法比个人期望的多了一点，想不出其他库有同样充分的理由采用此方案
URL：
https://ivakin.dev/blog/how-playwright-fixtures-work
《npm 上 ESM 与 CJS 的占比变迁数据》
标签：#JavaScript #NodeJS #ESM #CommonJS #npm #模块系统
总结：
该项目持续追踪 npm 高影响力（热门）包中 ESM、CJS、Dual（双模式）及 Faux（伪 ESM）的占比变化。数据显示，纯 ESM 包从 2021 年 8 月的 6% 增长至 2026 年 6 月的 16%；Dual 模式包增长最为迅猛（从 1.7% 到 22%），成为主流过渡方案；而纯 CJS 虽仍占最大份额（52%），但占比持续下降。2025 年底样本量骤增，反映 npm 生态整体扩张。
文章要点：
1. 纯 ESM 稳步增长但尚未过半**：从 2021 年 341 个包（6.1%）增至 2026 年 2590 个（16.0%），五年增长约 2.6 倍，但仍是少数派
2. **Dual 模式成为最大赢家**：从 95 个（1.7%）暴涨至 3574 个（22.0%），说明"同时支持 ESM 和 CJS"已成为库作者最务实的选择
3. **纯 CJS 仍是主流但份额萎缩**：从 77.4% 降至 51.6%，虽然绝对数量增加，但相对占比持续被侵蚀
4. "伪 ESM"（Faux）长期僵持**：表面用 ESM 语法但实际编译为 CJS 的包，占比一直维持在 10% 左右，说明彻底转型仍有阻力
5. **生态规模急剧扩张**：样本包总数从 5617 个增至 16231 个，2025 年底几乎翻倍，反映 npm 整体生态的蓬勃发展
6. **数据方法论透明**：基于
URL：
https://github.com/wooorm/npm-esm-vs-cjs#data
标签：#JavaScript #NodeJS #ESM #CommonJS #npm #模块系统
总结：
该项目持续追踪 npm 高影响力（热门）包中 ESM、CJS、Dual（双模式）及 Faux（伪 ESM）的占比变化。数据显示，纯 ESM 包从 2021 年 8 月的 6% 增长至 2026 年 6 月的 16%；Dual 模式包增长最为迅猛（从 1.7% 到 22%），成为主流过渡方案；而纯 CJS 虽仍占最大份额（52%），但占比持续下降。2025 年底样本量骤增，反映 npm 生态整体扩张。
文章要点：
1. 纯 ESM 稳步增长但尚未过半**：从 2021 年 341 个包（6.1%）增至 2026 年 2590 个（16.0%），五年增长约 2.6 倍，但仍是少数派
2. **Dual 模式成为最大赢家**：从 95 个（1.7%）暴涨至 3574 个（22.0%），说明"同时支持 ESM 和 CJS"已成为库作者最务实的选择
3. **纯 CJS 仍是主流但份额萎缩**：从 77.4% 降至 51.6%，虽然绝对数量增加，但相对占比持续被侵蚀
4. "伪 ESM"（Faux）长期僵持**：表面用 ESM 语法但实际编译为 CJS 的包，占比一直维持在 10% 左右，说明彻底转型仍有阻力
5. **生态规模急剧扩张**：样本包总数从 5617 个增至 16231 个，2025 年底几乎翻倍，反映 npm 整体生态的蓬勃发展
6. **数据方法论透明**：基于
npm-high-impact 热门包分析，爬取 package.json 的 latest 版本，约 15 分钟完成，结果以 CSV 和 SVG 可视化呈现URL：
https://github.com/wooorm/npm-esm-vs-cjs#data
GitHub
GitHub - wooorm/npm-esm-vs-cjs: Data on the share of ESM vs CJS on the public npm registry
Data on the share of ESM vs CJS on the public npm registry - wooorm/npm-esm-vs-cjs
《CSS 与 JavaScript 动画性能之争》
标签：#前端 #CSS动画 #JavaScript动画 #WebAnimationsAPI #性能优化 #GSAP #Motion
总结：
本文通过交互式演示拆解了 CSS 与 JS 动画的性能差异真相：CSS Keyframes 和 Transitions 运行在独立线程，主线程阻塞时依然流畅；而传统 JS 动画（如 requestAnimationFrame 循环）与主线程争抢资源，容易卡顿。但 Motion 库通过底层调用 Web Animations API（WAAPI）绕过了这一限制，实现了与 CSS 同级别的流畅度。作者建议优先使用原生 CSS，遇到 CSS 无法覆盖的场景时选择 Motion 等 WAAPI 方案，而非直接上 GSAP 这类纯主线程库。
文章要点：
1. CSS 动画的核心优势不是"计算快"，而是运行在独立线程，主线程再忙也不影响动画流畅度
2. 传统 JS 动画（requestAnimationFrame）每帧都在主线程计算，React 重渲染或 fetch 解析时容易掉帧
3. Motion 库（原 Framer Motion）底层使用 Web Animations API，能接入与 CSS 相同的底层动画引擎，主线程阻塞时照样丝滑
4. GSAP 功能极其强大，但坚持在主线程运行，是"能力换性能"的取舍，适合复杂序列动画而非简单过渡
5. 现代 CSS 已经很能打，View Transitions、linear()、Animation Timeline 等新 API 大幅减少了必须上 JS 的场景
6. 选型建议：能用 CSS 就不用库 → CSS 搞不定优先选 Motion/WAAPI → 只有复杂时间线控制才考虑 GSAP
URL：https://www.joshwcomeau.com/animation/css-vs-javascript/
标签：#前端 #CSS动画 #JavaScript动画 #WebAnimationsAPI #性能优化 #GSAP #Motion
总结：
本文通过交互式演示拆解了 CSS 与 JS 动画的性能差异真相：CSS Keyframes 和 Transitions 运行在独立线程，主线程阻塞时依然流畅；而传统 JS 动画（如 requestAnimationFrame 循环）与主线程争抢资源，容易卡顿。但 Motion 库通过底层调用 Web Animations API（WAAPI）绕过了这一限制，实现了与 CSS 同级别的流畅度。作者建议优先使用原生 CSS，遇到 CSS 无法覆盖的场景时选择 Motion 等 WAAPI 方案，而非直接上 GSAP 这类纯主线程库。
文章要点：
1. CSS 动画的核心优势不是"计算快"，而是运行在独立线程，主线程再忙也不影响动画流畅度
2. 传统 JS 动画（requestAnimationFrame）每帧都在主线程计算，React 重渲染或 fetch 解析时容易掉帧
3. Motion 库（原 Framer Motion）底层使用 Web Animations API，能接入与 CSS 相同的底层动画引擎，主线程阻塞时照样丝滑
4. GSAP 功能极其强大，但坚持在主线程运行，是"能力换性能"的取舍，适合复杂序列动画而非简单过渡
5. 现代 CSS 已经很能打，View Transitions、linear()、Animation Timeline 等新 API 大幅减少了必须上 JS 的场景
6. 选型建议：能用 CSS 就不用库 → CSS 搞不定优先选 Motion/WAAPI → 只有复杂时间线控制才考虑 GSAP
URL：https://www.joshwcomeau.com/animation/css-vs-javascript/
Joshwcomeau
CSS vs. JavaScript • Josh W. Comeau
There are a bunch of JavaScript animation libraries out there, and you might have wondered whether there’s a performance cost compared to traditional CSS transitions and keyframe animations. In this blog post, we’ll compare the same animation across several…
《嵌套Promise的实际用途》
标签：#JavaScript #Promise #并发控制 #RWLock #函数式编程
总结：
文章探讨了JavaScript中Promise自动扁平化设计的利弊。作者回顾了Promise/A+规范制定时关于是否引入Monad和Functor概念的争论，并通过实现读者-写者锁（RWLock）的实际案例，展示了嵌套Promise在并发控制中的独特价值——它能让一个异步函数调用另一个异步函数，却不阻塞等待内层函数完成，从而实现精细的并发管理。
文章要点：
- Promise的
- 函数式编程社区曾希望Promise能区分
- 作者在开发EscoDB时遇到了一个真实场景：实现读者-写者锁（RWLock）需要协调多个读操作并发执行、写操作独占执行
- 通过显式返回
- 嵌套Promise代表"一个异步函数调用另一个异步函数，但不等待其完成"的语义，在主动管理并发控制时非常有用
- Promise扁平化本质上是"时间上的连接"（强制顺序执行），而嵌套Promise则保留了并行调度的可能性
文章URL：https://blog.jcoglan.com/2026/03/23/uses-for-nested-promises/
标签：#JavaScript #Promise #并发控制 #RWLock #函数式编程
总结：
文章探讨了JavaScript中Promise自动扁平化设计的利弊。作者回顾了Promise/A+规范制定时关于是否引入Monad和Functor概念的争论，并通过实现读者-写者锁（RWLock）的实际案例，展示了嵌套Promise在并发控制中的独特价值——它能让一个异步函数调用另一个异步函数，却不阻塞等待内层函数完成，从而实现精细的并发管理。
文章要点：
- Promise的
then()方法同时承担了Functor的map和Monad的flatMap功能，会自动扁平化任意层级的嵌套Promise- 函数式编程社区曾希望Promise能区分
map()和flatMap()，但规范作者出于便利性考虑拒绝了这一提议- 作者在开发EscoDB时遇到了一个真实场景：实现读者-写者锁（RWLock）需要协调多个读操作并发执行、写操作独占执行
- 通过显式返回
{ promise: Promise<T> }结构来"绕过"Promise自动扁平化，实现了关键功能：保护"检查队列状态"和"放入任务"这两个动作的原子性，同时又不阻塞调度器等待任务实际执行完成- 嵌套Promise代表"一个异步函数调用另一个异步函数，但不等待其完成"的语义，在主动管理并发控制时非常有用
- Promise扁平化本质上是"时间上的连接"（强制顺序执行），而嵌套Promise则保留了并行调度的可能性
文章URL：https://blog.jcoglan.com/2026/03/23/uses-for-nested-promises/
《2026年JavaScript生态全景指南》
标签：#前端 #JavaScript #ECMAScript2025 #ECMAScript2026 #React #Vue #Svelte #NodeJS #TypeScript #Vite #Bun #Deno #TemporalAPI #IteratorHelpers #ImportAttributes
总结：
本文全面梳理了2026年JavaScript生态系统的最新发展，涵盖ECMAScript 2025（迭代器助手、Set方法、Promise.try等）和2026预期特性（Temporal API、资源管理），React/Vue/Svelte框架动态，Node.js原生TypeScript支持、Bun和Deno运行时竞争，Vite 8与Turbopack构建工具演进，TypeScript v6及AI编程趋势。文章强调掌握基础原理比追逐工具更重要，特别是在AI辅助编程时代，架构能力和代码品味尤为关键。
文章要点：
- **ECMAScript 2025超实用新玩具**：迭代器终于能链式调用`.map()
- **2026年最期待的Temporal API**：Date对象终于被拯救了！处理时区和日期计算不会再莫名其妙多出几天，浏览器原生支持即将到来，告别 moment.js 大礼包的时代要来啦～
- **框架圈的大新闻**：React 19的Server Components和Compiler还在消化中，Vue 3.6祭出Vapor Mode性能大招，Svelte 5的Runes API让响应式更细粒度； Next.js 16默认切到Turbopack，Astro被Cloudflare抱走，Remix正在酝酿去React化的大胆实验～
- **运行时三国杀**：Node.js 22+能直接跑.ts文件啦（虽然只是剥离类型），Bun被Anthropic(Claude家)收编后1.3版本速速飞起，Deno 2稳如老狗主打安全牌，三足鼎立格局越来越有意思～
- **TypeScript登顶GitHub第一**：v6严格模式默认开启，v7要用Go重写编译器提速10倍；92%的开发者都在用AI写代码，但文章提醒我们——基础原理和架构品味才是AI时代真正的护城河呀！
文章URL：https://frontendmasters.com/blog/what-to-know-in-javascript-2026-edition/
标签：#前端 #JavaScript #ECMAScript2025 #ECMAScript2026 #React #Vue #Svelte #NodeJS #TypeScript #Vite #Bun #Deno #TemporalAPI #IteratorHelpers #ImportAttributes
总结：
本文全面梳理了2026年JavaScript生态系统的最新发展，涵盖ECMAScript 2025（迭代器助手、Set方法、Promise.try等）和2026预期特性（Temporal API、资源管理），React/Vue/Svelte框架动态，Node.js原生TypeScript支持、Bun和Deno运行时竞争，Vite 8与Turbopack构建工具演进，TypeScript v6及AI编程趋势。文章强调掌握基础原理比追逐工具更重要，特别是在AI辅助编程时代，架构能力和代码品味尤为关键。
文章要点：
- **ECMAScript 2025超实用新玩具**：迭代器终于能链式调用`.map()
和.filter()`啦，而且是惰性求值不耗内存；Set之间可以玩集合运算，轻松找出技能交集和差集；`Promise.try()`让同步异步错误一网打尽；还有`RegExp.escape()`终于解决了用户搜索时特殊字符炸正则的问题～- **2026年最期待的Temporal API**：Date对象终于被拯救了！处理时区和日期计算不会再莫名其妙多出几天，浏览器原生支持即将到来，告别 moment.js 大礼包的时代要来啦～
- **框架圈的大新闻**：React 19的Server Components和Compiler还在消化中，Vue 3.6祭出Vapor Mode性能大招，Svelte 5的Runes API让响应式更细粒度； Next.js 16默认切到Turbopack，Astro被Cloudflare抱走，Remix正在酝酿去React化的大胆实验～
- **运行时三国杀**：Node.js 22+能直接跑.ts文件啦（虽然只是剥离类型），Bun被Anthropic(Claude家)收编后1.3版本速速飞起，Deno 2稳如老狗主打安全牌，三足鼎立格局越来越有意思～
- **TypeScript登顶GitHub第一**：v6严格模式默认开启，v7要用Go重写编译器提速10倍；92%的开发者都在用AI写代码，但文章提醒我们——基础原理和架构品味才是AI时代真正的护城河呀！
文章URL：https://frontendmasters.com/blog/what-to-know-in-javascript-2026-edition/
Frontend Masters
What To Know in JavaScript (2026 Edition)
We’ve done posts like this for CSS, but JavaScript deserves the same dangnabit! Especially as JavaScript does a better job of versioning itself anyway. We’ll cover new stuff in the language itself, but being a JavaScript practitioner involves more than the…
《原生JSON模块终于成为现实》
标签：#JavaScript #ESModules #JSON #Web标准
总结：本文介绍了JavaScript平台原生支持JSON模块导入的新特性。通过使用
文章要点：
- 使用
- 动态导入同样支持：
- 导入的JSON会被解析一次并缓存，多次导入返回同一对象实例（
- 浏览器仍需服务器返回
- 与打包工具方案对比：原生方案在运行时获取文件，而打包工具通常在构建时内联JSON
- 此特性不仅限于JSON，已扩展支持CSS模块脚本（
- 现代浏览器、Node.js、Deno、Bun均已支持该特性，但打包工具在代码分割、资源哈希等方面仍有价值
文章URL：https://allthingssmitty.com/2026/03/16/native-json-modules-are-finally-real/
标签：#JavaScript #ESModules #JSON #Web标准
总结：本文介绍了JavaScript平台原生支持JSON模块导入的新特性。通过使用
import attributes语法with { type: "json" }，开发者现在可以在浏览器、Node.js、Deno和Bun中直接导入JSON文件，无需构建工具转换。这标志着从构建时模拟到运行时原生支持的转变，使模块系统更加显式和可扩展。文章要点：
- 使用
import config from "./config.json" with { type: "json" }语法实现原生JSON导入，替代了以往需要打包工具转换的方式- 动态导入同样支持：
await import("./config.json", { with: { type: "json" } })- 导入的JSON会被解析一次并缓存，多次导入返回同一对象实例（
a === b为true）- 浏览器仍需服务器返回
Content-Type: application/json，并遵循CORS规则- 与打包工具方案对比：原生方案在运行时获取文件，而打包工具通常在构建时内联JSON
- 此特性不仅限于JSON，已扩展支持CSS模块脚本（
with { type: "css" }），为未来其他结构化模块类型建立模式- 现代浏览器、Node.js、Deno、Bun均已支持该特性，但打包工具在代码分割、资源哈希等方面仍有价值
文章URL：https://allthingssmitty.com/2026/03/16/native-json-modules-are-finally-real/
《利用浏览器Canvas进行数据压缩》
标签：#前端 #JavaScript #CanvasAPI #数据压缩 #PNG编码 #浏览器兼容性 #SPA
总结：本文介绍了一种利用浏览器Canvas API将任意数据压缩为PNG图像格式的技术方案。通过将字节数据编码为像素颜色值并生成PNG图像，可以间接调用浏览器内置的压缩算法，实现无需外部依赖的数据压缩。该方法特别适用于需要在旧版浏览器中压缩数据、或需要将SPA状态序列化到URL中的场景，提供了Compression Streams API不可用时的替代方案。
文章要点：
- 背景需求：在静态网站和SPA中，有时需要将状态数据序列化到URL hash中，因此需要前端数据压缩方案；虽然2023年5月后Compression Streams API已普及，但旧版浏览器仍需替代方案
- 核心原理：浏览器内置了优化的压缩库用于HTTP请求和图片处理，通过将数据编码为PNG像素数据，可间接利用浏览器的无损压缩能力
- 技术实现：将Uint8Array数据按RGB通道编码到Canvas像素中（首字节存储最后一像素的有效字节数），Alpha通道固定为255以确保跨浏览器一致性，最终通过toDataURL("image/png")获取base64编码的压缩数据
- 解压流程：异步加载生成的PNG图片，读取像素数据后过滤Alpha通道，根据首字节指示的有效长度提取原始字节数据
- 方案特点：即使考虑PNG格式开销，压缩后的数据通常仍小于原始数据；完全基于浏览器原生API，无需外部库依赖
- 应用场景：旧浏览器兼容性支持、URL状态序列化、纯前端数据压缩需求
文章URL：https://jstrieb.github.io/posts/canvas-compress/
标签：#前端 #JavaScript #CanvasAPI #数据压缩 #PNG编码 #浏览器兼容性 #SPA
总结：本文介绍了一种利用浏览器Canvas API将任意数据压缩为PNG图像格式的技术方案。通过将字节数据编码为像素颜色值并生成PNG图像，可以间接调用浏览器内置的压缩算法，实现无需外部依赖的数据压缩。该方法特别适用于需要在旧版浏览器中压缩数据、或需要将SPA状态序列化到URL中的场景，提供了Compression Streams API不可用时的替代方案。
文章要点：
- 背景需求：在静态网站和SPA中，有时需要将状态数据序列化到URL hash中，因此需要前端数据压缩方案；虽然2023年5月后Compression Streams API已普及，但旧版浏览器仍需替代方案
- 核心原理：浏览器内置了优化的压缩库用于HTTP请求和图片处理，通过将数据编码为PNG像素数据，可间接利用浏览器的无损压缩能力
- 技术实现：将Uint8Array数据按RGB通道编码到Canvas像素中（首字节存储最后一像素的有效字节数），Alpha通道固定为255以确保跨浏览器一致性，最终通过toDataURL("image/png")获取base64编码的压缩数据
- 解压流程：异步加载生成的PNG图片，读取像素数据后过滤Alpha通道，根据首字节指示的有效长度提取原始字节数据
- 方案特点：即使考虑PNG格式开销，压缩后的数据通常仍小于原始数据；完全基于浏览器原生API，无需外部库依赖
- 应用场景：旧浏览器兼容性支持、URL状态序列化、纯前端数据压缩需求
文章URL：https://jstrieb.github.io/posts/canvas-compress/
#React 学习如何使用 React Three Fiber 创建一个简化版的移动游戏《跳跳路》的克隆版。#ReactThreeFiber #Threejs #JavaScript #TypeScript
https://javascriptgametutorials.com/tutorials/react-three-fiber/crossy-road
https://javascriptgametutorials.com/tutorials/react-three-fiber/crossy-road
JavaScript Game Tutorials
Crossy Road with React Three Fiber
In this tutorial, we learn how to create a simplified clone of the mobile game Crossy Road with React Three Fiber.
