MoonWebTeam前端技术月刊致力于分享和推广前端技术的最新进展和优秀文章。我们在推荐文章的同时，也会分享团队内小伙伴对这些文章的深度解读与独到见解，以期为读者提供更多的思考角度和实践参考。欢迎广大 Web 前端技术爱好者关注MoonWebTeam前端团队 ，一起探索前端技术的无限可能！
1、前端框架
1.1、React 19 和 Compiler
文章链接：
简介：
这两篇文章给大家带来了 React 最新的内容。随着 React 19 的正式发布，它带来了一系列新特性和改进，旨在提升开发者的使用体验并进一步优化 React 应用的性能。第一篇文章详细介绍了 React 19 的新特性，如 Actions、全新的Hook（例如 useActionState 和 useOptimistic），以及对 <form> 元素的改进。此外，还探讨了 React 19 对服务器组件的支持，包括服务器操作和服务器组件的集成。文章还提到了React 19在错误报告、自定义元素支持、样式表和脚本管理等方面的改进。
React 最新带来的 React Compiler 目前还是一个实验性的工具，它旨在帮助开发者优化React应用的性能，特别是在组件更新方面。第二篇文章作者分享了自己对 React Compiler 的深度使用体验，并结合实践案例详细分析了其实现原理。
见解与看法：
React 的最新进展表明，React 团队正致力于提升开发体验和应用性能。React 19 通过引入新的 API 和改进，如 useActionState 和表单 Actions，简化了异步状态管理和表单处理，同时提供了对服务器组件的全面支持，为构建全栈 React 应用打下基础。React Compiler 作为一项创新技术，通过元素级的细粒度更新，自动化了缓存机制，减少了开发者手动优化的工作量，从而提高了运行时性能。
尽管这些特性令人兴奋，但它们目前还处于测试阶段，并不推荐在生产环境中使用。开发者在编写代码时，应遵循 React 的规则和最佳实践，确保将来能够无缝接入 React Compiler 正式版，享受其带来的性能优势。随着 React 19 和 React Compiler 的不断发展和完善，我们期待它们将为前端开发带来革命性的改变，进一步提升开发效率和用户体验。
1.2、Rust Farm
文章链接：
简介：
本文主要介绍了 Rust Farm v1.0 版本的正式发布，这是一个基于 Rust 语言编写的下一代 Web 构建引擎。文章详细描述了 Farm 的各种功能和优势，包括极致性能、增量构建、懒编译、海量特性、插件化和 Vite 兼容性等。同时，文章还提到了 Farm 在基准测试中的优越性能，以及一些企业级项目迁移到 Farm 后的成功案例。
见解与看法：
目前，社区中已经出现了许多使用 Rust 编写的前端构建工具，如 Fram、Rspack、RsBuild、Rolldown 等，这些工具旨在解决使用 JavaScript 编写的构建工具在热模块替换（HMR）和构建性能方面的问题。
我们团队在使用 Vite 开发和构建项目时，遇到以下问题：
- 开发和生产环境不一致：vite dev 基于 esbuild，而生产环境基于 rollup，这导致了开发和生产环境之间的不一致性，发生错误难以排查。
- 基于 JavaScript 的 Rollup 构建存在性能瓶颈：由于我们的活动场景需要每次发布时重新打包构建，对构建性能的要求较高。
针对这些问题，Rolldown 是尤大基于 Rust 开发的新构建工具，但目前仍处于开源状态，尚未发布正式版本。Farm 相较于 Rspack 和 RsBuild，适配了 Vite 和 Rollup 的插件，可以复用 Vite 的生态，现有基于 Vite 构建的项目迁移成本较低。然而，由于 Farm 是一个小团队的产物，未来可能存在不更新的风险。
1.3、StyleX
文章链接：
简介： 本文主要介绍了 Meta 在 2023年底开源的一款定位类似JSX的CSS-in-JS库StyleX**；**看下来对较大的工程项目具备如下优势
- 禁用了影响子孙样式的CSS选择器，避免CSS冲突和维护难度（可通过js props传参的灵活性弥补）
- 生成可复用的原子类名，随着项目体积增大也有效控制合理的CSS体积
- 预编译生成css文件，避免了传统CSS-in-JS库在运行时解析的性能损耗
- 支持样式的类型安全检查，如基础组件在定义css props入参时可声明类型约束（相比TailwindCSS)
见解与看法：
StyleX 跟其他 CSS-inJS 库区别在于，StyleX 是通过预编译生成 css 内容，从而解决运行时解析带来的性能开销。StyleX 提供了一种强约束的样式规范，禁用了可能造成混淆的选择器，保障样式类型的安全检查，用 JS 的灵活性弥补这部分功能的缺失。比较适合于大型且维护周期比较长的多人合作项目，通过强约束的样式规范来统一项目的规范，但是在在小型项目上使用写法稍显繁琐。
2、性能优化
2.1、网易云音乐桌面版前端性能优化
文章链接：
简介： 本文主要介绍了网易云音乐桌面版在前端性能优化上的重构过程，首先在背景上分析目前所遇到的痛点与挑战，然后围绕着重播放起播耗时长、交互卡顿明显和系统资源占用大这三个问题进行深入的分析并给出了具体的解决方案：
- 播放起播耗时长
首先从用户角度进行分析，在用户的播放体验中，播放起播耗时长有着举足轻重的作用，因为它直接影响用户在点击播放按钮后能够听到音乐的时间。为了提升用户体验，他们针对性地分析了导致起播耗时长的原因主要有歌曲列表接口分页请求耗时和播放信息（State）更新导致视图渲染阻塞起播流程。
针对歌曲列表接口分页请求耗时长问题，他们充分考虑了用户在实际使用场景中的行为和需求，利用了用户进入歌单页面到开始播放歌单之间的空闲时间实现获取完整的歌曲列表接口的预加载，以减少用户在播放过程中等待接口请求的时间。而在渲染调优方面，关用户在播放过程中与订阅播放状态相关的组件的渲染性能，对订阅播放状态相关的组件进行渲染优化，通过解构和降低组件复杂度减少 render 和 re-render 成本。
- 交互卡顿明显
针对原有的 ActionProvider 组件带来的性能问题，UI 声明事件转 JavaScript 事件调用。原来是通过 UI 声明式的配置的方式进行统一的事件注册，由于是一套统一方案，虽然使得应用中的核心事件的注册、实现和维护变得简单，但是由于依赖或 Props 变化过于离散，导致存在大量的 re-render。
- 系统资源占用大
这篇文章还讨论了系统资源占用优化的，包括 CPU、GPU 和内存上的优化：
- CPU 优化：通过动画按需执行来实现 CPU 资源占用问题，当应用切换到后台状态时，自动暂停CSS动画的执行，避免相关的资源占用持续占用。
- GPU 优化：通过 backdrop-filter 全局 CSS 和视口外 DOM 管理来实现 GPU 的优化。通过禁用底部播放条的高斯模糊，改用类似的静态颜色替代，以及调整底部播放条的DOM结构，通过合适的合成层优化，将转动的黑胶唱片从高斯模糊的计算范围中剔除。
- 内存优化：主要通过清除非必要引用来实现，通过浏览器 devtools 排查到埋点 SDK 通过 MutationObserver 监听 DOM 元素的挂载并进行记录保存，用于在 DOM 曝光时上报节点路径。但是在 DOM 元素卸载时没有及时地清除相关引用，引发了本次全局性的内存泄漏。
见解与看法：
整篇文章较为详细地讲述了网易云音乐桌面版在前端性能优化上的重构过程，他们做得比较好的值得我们借鉴的主要有三点：
- 站在用户的角度去思考和分析性能问题：
在播放起播耗时长优化部分，首先站在用户的角度去分析到播放起播耗时长是最影响用户使用体验的问题，然后围绕这个问题去寻找性能上的瓶颈并优化，其次在系统资源占用优化部分，他们对于性能优化并不是盲目优化、高成本追求极致，而是要根据具体的场景和优化成本进行。比如黑胶转盘的动画导致 CPU 占用率较高，首先用户在网易云音乐前台的时候才需要看到这个动画，其次在前台 CPU 占用率高也是可接受的，需要优化的是在后台时的 CPU 占用，所以成本比较低的优化方案就是当应用切后台时暂停相关动画的执行，而不是一上来就需要通过原生组件渲染来优化。
- 动态 CSS 渲染优化的方法：
原生的 HTML 标签 div、在行内 style 定义 CSS Variable 和在 CSS 中使用定义的 CSS Variable 来实现动态 CSS，降低使用 CSS-in-JS 创建的冗余的 React Component 带来的冗余渲染开销，因为 CSS-in-JS 所提供的 styled.div 来实现动态 CSS 的本质是在编译时创建一个 React Component 来根据 Props 进行动态的渲染，这会导致组件树变得复杂，增加了渲染的成本。
- 定位和排查内存泄露的思路与方法：
在系统资源内存占用优化部分，他们提供了较为详细的通过浏览器 devtools 逐步排查和定位 DOM 元素引用导致内存泄露问题的思路，例如，首先通过 Performance Monitor 定性内存泄漏问题，然后通过 Detached Elements 定位内存泄漏源头，最后 Memory 可以出分析内存泄漏路径，然后可以找出内存泄露的根本原因。
3、AI 相关
3.1、最强人形机器人
文章链接：
简介：
本文主要介绍了人形机器人的定义、应用及中国在该领域的进展。特斯拉的人形机器人Optimus近日亮相工厂，展示了其在现实生产线上的应用能力，这一幕不仅引发了公众的广泛关注，也标志着人形机器人时代的来临。工信部发布的《人形机器人创新发展指导意见》将人形机器人与计算机、智能手机、新能源汽车等革命性产品并列，预示着其将深刻改变我们的生产和生活方式。
人形机器人的核心在于“具身智能”，即为人工智能提供一个能够在物理世界中感知、思考和行动的载体。这一技术的发展，使得机器人不再局限于执行单一任务，而是能够在多种场景中与人类协作，提高通用性。随着技术的进步，人形机器人的应用前景被看好，预计不久的将来，它们将不仅在工业制造领域，而且在家庭服务等多个领域发挥重要作用。中国在人形机器人的发展上正迈出坚实步伐，预计在不远的将来，这些高科技的助手将成为我们日常生活的一部分。
见解与看法：
人形机器人正踏上产业化的征途，预期在2024年迈入量产的新纪元。在人工智能技术的赋能下，这些机器人已经超越了传统机器人的限制，具备了执行多样化任务的能力，从而极大地增强了它们的适用性。选择人形设计而非传统的滚轮或其他形态，是基于其更好地融入人类的生活环境和更加灵活地操作工具的需求。同时，人形机器人的外观更易引发人类的共鸣和亲切感。这些综合因素预示着人形机器人在未来的应用领域将具有无限可能。
3.2、ChatTTS突破语音生成天花板
文章链接：
简介：
ChatTTS是一个对话式的高可控语音合成模型，能够生成自然流畅的语音，并控制笑声、停顿和语气词等副语言现象。它支持中英文混说，并且能够复刻已逝去人的声音，如乔布斯或泰勒·斯威夫特的音色。
ChatTTS的主要特点包括：
- 支持多说话人和混合语言输入。
- 能够精确控制韵律元素，如笑声、停顿和语调。
- 支持细粒度控制，允许用户加入特定的语音元素。
- 能够复刻特定人物的声音，模仿得非常接近本人。
ChatTTS可以在线体验，并且有两种核心功能：文字转语音和与大语言模型的实时语音对话。用户可以在“Audio Seed”处调节数字指定说话人的音色，或者随机生成音色。不过，ChatTTS目前还不能处理长文本，初始版本不能生成超过30秒的音频，且在处理长文本时分词可能会有问题。
见解与看法：
如果这项技术普及开来，那影响的行业将非常多，可以改善无障碍服务、个性化语音助手、语言学习和翻译、虚拟角色和偶像、内容创作等，上一个让人类似耳目一新的时刻还是 ChatGPT4o 的发布会，从冰冷的人工合成语音转换成极富真实感情色彩的人声，距离硅基生命的到来越来越近了。
3.3、Chrome 126 开始将内置集成 Gemini Nano
文章链接：
简介：
Chrome 126 开始将内置集成 Gemini Nano，用户使用 Gemini Nano 可以实现翻译、转录等功能，同时在后续版本中将支持 Chrome DevTools， 换言之，Gemini 可以辅助进行 Chrome调试。
Gemini Nano 是 Google 去年引入Pixel 8 Pro 和 Pixel 8 手机的轻量级大型语言模型。为了将其带入 Chrome 浏览器，Google 对模型进行了优化调整，并确保浏览器能够快速加载该 AI 模型。得益于这项新功能，用户将能在 Chrome 浏览器中直接生成产品评论、社交媒体帖子等内容。这与微软在 Edge 浏览器中集成 Copilot AI 助手的做法类似，不过不同的是 Copilot 需要连接云端服务器，而 Gemini Nano 则是在本地运行。
- Chrome 浏览器集成了 Gemini Nano 人工智能（AI）功能，旨在提升用户的浏览体验。
- 这些 AI 功能包括文本生成、翻译、字幕和文本转录等。
- Chrome DevTools 内置 AI 还能够帮助开发者更敏捷的开发网页应用。
见解与看法：
对用户日常使用而言，本地大模型首先带来的肯定是信息的隐私化和安全化，Gemini Nano 本地化可以带来更快的响应时间和更低的延迟，这对于需要即时反馈和处理的应用场景，如实时翻译和转录，是一个显著的优势；集成 AI 功能如翻译和转录，可以极大地丰富用户的浏览体验，例如看外文文献、影视等。这使得 Chrome 成为一个更加全面的通信和学习工具。而对我们开发使用而言，Chrome DevTools 中提供 Gemini 功能，我们可以根据 Gemini 的解释错误信息，以及其提供的解决编码问题建议来调试和调整我们的应用程序。虽然目前还实际体验不到，但是可以想象这里的空间还是很大。
4、领域驱动设计 DDD
4.1、领域驱动设计 DDD 在 B端营销系统的实践
文章链接：
简介： 这篇文章是关于领域驱动设计（Domain-Driven Design，简称DDD）在B端营销系统实践中的介绍和应用。文章从背景、基本概念、战略设计实践、战术设计实践、代码架构实践、总结以及参考资料几个方面进行了详细阐述。
文章开头提到，为了实现商户增长和留存，美团构建了相应的营销系统。在系统建设过程中，面临业务体量大、行业跨度大、场景多样、客户结构复杂和需求多变等挑战。DDD作为一种应对软件设计复杂性的方法，被提出来解决这些问题。文章解释了软件系统的复杂性主要体现在隐晦性、耦合性和变化性三个方面。DDD通过统一语言、概念模型和代码模型来解决这些复杂性问题。战略设计部分讨论了如何确定用例、统一语言、划分边界，以及如何通过用例图、用户故事、交互原型和事件风暴等方法来理解业务。文章强调了统一语言的重要性，以及如何通过概念模型来理解和组织业务。战术设计部分介绍了如何将概念模型转化为代码模型，包括实体和值对象的区别、聚合根的设计原则，以及如何避免陷入事务脚本的陷阱。代码架构部分讨论了如何组织代码架构，包括领域层、应用层、基础设施层和用户接口的设计。文章提到了六边形架构、整洁架构和洋葱架构等概念，并展示了美团团队的工程实践。文章最后总结了DDD在B端营销系统实践中的关键点，包括重视统一语言、领域驱动设计是团队工作、拥抱变化和持续迭代等。同时，文章也指出了一些常见的DDD实践误区。
从理论到实践，再到常见问题的解决，内容详实且具有很高的参考价值。
见解与看法：
在学习DDD领域驱动设计时，现成的大部分资料都是偏理论，在实践上很少有完整的项目设计是按照DDD的设计步骤来执行，这篇文章讲DDD设计过程中每个步骤的设计思路以及如何跟实际项目设计做结合都罗列的非常清晰，包括画图也很明确。作为学习DDD实践知识的一篇不错的材料，推荐阅读。
5、最佳实践
5.1、Font2svg 特殊字体渲染方案
文章链接：
简介：
本文主要介绍了B 站的动态特殊字体的解决方案。为了保证页面性能，区别于通过使用原始字体、裁剪字体和切图的方式，本文提出了将单个字符转成 SVG 的方式来渲染的方案，这就需要提前将字体库中的所有字符都转成 SVG 然后上传到 CDN 中，当用户用到什么字符就按需从 CDN 中请求什么字符。
优化后渲染文字所需资源、首屏加载时长、页面跳失率都有比较明显的优化效果。当然，该方案还是存在一些不足：渲染资源体积随着需要渲染的特殊字符的增加而增加，如果字符很多，就需要多次小文件的网络请求，网络请求失败超时的概率就会上升，有可能出现其中几个字符无法渲染，最终兜底到系统字体。
见解与看法：
在我们的实际业务中，对于特殊字体的渲染最常用的两种方式就是切图和字体裁剪，对于大量动态的特殊字体一般会让设计同学放弃特殊字体，为页面性能做一些妥协。font2svg 本质上是一种按需引入的字体库的思路，相较于传统的使用 Fontmin 分析页面字符导出所需要的字体的字体包文件，通过 Font2svg 的方案就可以实现更灵活、高效的特殊字体渲染能力，让页面的用户体验更加友好。
5.2、前端统一请求库设计与落地
文章链接：
简介：
本文主要介绍了B站前端团队在前端统一请求库方面的设计思路。首先讲述了他们在实际业务开发中遇到的典型问题：可维护性、性能、前后端协同方面的问题，然后明确了统一请求库需要达成的目标，需要实现统一标准化、多端支持、集成基础设施并确保性能。
在架构设计方面，借鉴了 Axios 的拦截器和 Koa 的洋葱模型，通过中间件和职责链模式实现了灵活的插件可扩展机制，并将模块分为 API 层、控制层和成员层，其中控制层又包含配置控制器、装配控制器和请求控制器这三个职责分明的模块，整体架构比较清晰。
最终取得的收益也是显而易见的，各团队前端项目的请求方式得到了统一，灵活性和扩展性极大了简化了前端工作。
见解与看法：
在我们实际的项目中，由于项目历经多年迭代和多次交接，对于后台接口请求的方式也会非常不统一、非常混乱。为了代码的可维护性，统一是必须要做的事情。统一的方式有很多，包括后台接口协议上的统一、通过统一的后台接入层网关管理所有接口、以及本文提到的封装前端统一请求库。对于包含各种历史债务的场景，落地可行性强、成本比较低的无疑就是封装前端统一请求库，但需要重点考虑请求库的可扩展性和兼容性以及老项目的替换成本，本文在统一请求库的架构设计上给我们提供了一些可行的设计思路，比如插件的设计、分层分模块等。
最后，如果客官觉得文章还不错，👏👏👏欢迎点赞、转发、收藏、关注，这是对小编的最大支持和鼓励，鼓励我们持续产出优质内容。
6、 关于我们
MoonWebTeam目前成员均来自于腾讯，我们致力于分享有深度的前端技术，有价值的人生思考。
