小红书前端面经
小红书前端面经，低代码平台与 AI 生成页面技术解析
一面
低代码平台"夜酱"对标业内开源方案或大厂方案，有哪些创新设计？
- 服务场景差异化：聚焦游戏和游戏消费场景，为腾讯充值、王者荣耀等活动营销提供页面搭建服务，与业内多聚焦表单设计器的开源方案不同
- 核心创新点：结合AIGC技术，通过AI生成Schema实现页面渲染；底层依托"超级工厂"流程编排引擎，支持拖拽生成事件流、自定义编排事件触发逻辑
- 技术架构：基于腾讯内部低代码引擎开发，上层封装专属活动素材库组件（九宫格、抽奖、支付组件等）；采用Taro作为渲染器，支持小程序及多端扩展
小程序适配过程中遇到的难点及解决方案是什么？
核心难点：微信第三方平台授权受限，要求授权发起域名与授权事件接收域名必须为同一一级域名；内网平台配置内网域名后，第三方平台的ticket无法推送，导致无法获取access token，阻碍授权流程
备选方案及不足：
- 内网穿透：安全性和稳定性差，过度依赖工具
- 后端302跳转：需前端两次当前页面302跳转，用户体验不佳
最终方案（前端中转页）：部署中转页到C端服务，前端从内网系统通过新窗口跳转至中转页并携带参数（后端生成的授权页面URL，含预授权码、APP ID）；中转页解析参数后重定向至授权页；用户扫码授权后，中转页解析回调code并传递给C端服务，通过code与access token换取小程序信息，最后通过跨页面通信通知原页面
中转页的技术方案具体是怎样的？
- 跳转与参数传递：从内网系统通过open新窗口跳转至C端服务部署的中转页，URL携带后端生成的授权页面地址参数
- 参数解析与重定向：中转页解析URL参数，提取授权页面链接并跳转至授权页
- 授权回调处理：基于OAuth 2.0授权方式，用户授权后通过回调URL携带code返回中转页，中转页解析code并传递给C端服务，完成后续token换取
- 跨页面通信：授权完成后，通过前端跨页面通信通知原内网页面授权结果
"夜酱"生成的页面适配小程序时，在渲染层面遇到的问题及解决方案是什么？
核心问题：小程序不支持动态编码，需按WXML格式静态化；Taro存在兼容性问题
解决方案：
- 静态化处理：利用Taro的编译能力，结合自定义patch代码，将平台生成的动态内容打包为静态化小程序代码包
- 兼容性适配：通过
Object.defineProperty监听属性、props传递属性或设置空函数拦截等方式，兼容Taro不支持的API，避免报错；部分API通过内部封装方法实现功能
业内低代码平台的预览方式有哪些？"夜酱"的预览方案是什么？
业内常见方式：页面内模拟WebView窗口实现实时预览，本质依赖浏览器能力，属于"假预览"
"夜酱"方案（全真实真机调试）：
- 借助小程序mini program CI工具，将生成的小程序代码包上传至第三方应用草稿箱，再迁移至模板库生成体验版
- 流程：获取页面协议→打包生成小程序代码包→上传至小程序开发板→CI工具返回Base64格式二维码，用户扫码即可真机预览
TDesign迁移中出现白屏和闪烁问题的原因及解决方案是什么？
问题场景：Dialog组件点击弹出/关闭时出现白屏、闪烁
核心原因：
- 动画库兼容性问题：组件使用的React Transition Group动画库与Vue 8版本不兼容，多个setState触发时执行顺序被覆盖
- 组件卸载异常：组件嵌套两层动画容器，外层动画执行完后内层组件未完全卸载，耗时任务阻塞主线程导致动画执行顺序错乱
解决方案：
- 临时修复：通过patch package修改本地node_modules，缩短外层动画时间（短于内层），确保外层卸载时内层动画已执行完毕
- 长期方案：提交MR移除冗余动画容器，彻底解决执行顺序冲突问题
包体积优化的具体配置优化指什么？
- 核心优化手段：通过external配置，将React、ReactDOM等公共依赖及8MB大小的编辑器（非全页面必需，跳转新页面加载）改为CDN引入，避免打包进项目
- 其他优化方向：统一内部组件库，减少重复依赖导致的包体积冗余
包体积优化后，打包时长的常见优化方案有哪些？
- 优化模块解析：配置resolve参数，让Webpack更快定位模块依赖路径
- 减少不必要打包：通过external、按需引入等方式剔除冗余依赖
- 开启多进程打包：提升并行处理效率（项目中已默认开启）
- 缓存优化：利用打包缓存机制减少重复构建（字节实习时了解过该方案，本项目未应用）
飞书文档/表格的UI绘制相关协议或规范是什么？
核心规范基于自定义DSL（领域特定语言），依托KVAS渲染引擎实现：
- 渲染流程接管：KVAS引擎完全接管浏览器layout和paint流程，不依赖浏览器原生渲染链路，通过收集绘制信息生成绘制列表，统一调用KVAS API渲染
- DSL核心原语：
- DIV：描述块级元素，支持背景、边框、圆角等样式
- Inline：核心排版原语，支持富文本文字排版
- Flex：提供复杂布局能力
- Superlist：上层扩展原语，适配文档/表格特定场景
- 性能优化：同类型元素一次性渲染，减少画笔切换导致的性能损耗
框架内部原语完善具体指什么？
指实现DIV组件的border-radius、border和outline样式支持：
- 技术难点：outline不属于盒模型，需结合border-radius的弧度计算绘制范围，涉及椭圆绘制及内部宽度、边框宽度、内边距的统一合并计算
- 实现逻辑：通过数学计算确定outline与边框的区域关系，基于椭圆绘制规则实现带弧度的outline样式
DevTools工具的开发背景是什么？
负责情况：后期独立owner，全程主导开发与优化
开发背景：
- 核心痛点：KVAS渲染引擎在浏览器开发者工具中仅显示为单个KVAS标签，内部DSL的层级结构无法可视化，开发需通过console面板逐层查看内存中的ElementTree对象，效率极低
- 工具目标：
- 可视化展示DSL层级结构，模拟浏览器Elements面板体验，支持hover查看节点属性、样式
- 透明化渲染流程，通过插件体系让开发者查看引擎内部渲染逻辑
- 版本迭代：从最初的浏览器插件版本，迭代为基于CDP协议的方案（本地起Node服务+页面插入SDK，通过WebSocket通信），最终封装为Electron版本提升稳定性
DevTools工具如何实现DOM元素与Canvas内部DSL节点的映射？
核心逻辑：
- 事件监听：监听鼠标hover到KVAS画布的事件，获取鼠标在画布中的坐标
- 节点匹配：通过引擎内部方法，根据坐标计算对应的DSL节点
- 数据传输：通过CDP协议将节点属性、样式等数据传输至工具面板，实现可视化映射
- 边界处理：仅当hover在KVAS区域时触发解析，其他区域仍保持浏览器原生Elements面板功能
状态回滚和重放的marker机制实现原理是什么？
核心思路：收拢样式修改日志并回放
- 日志收集：将所有RenderObject的样式修改（如DSL样式变更）统一收拢为方法调用，通过log方式记录所有修改操作
- 日志存储：将日志集合存储在window对象中
- 重放实现：DevTools工具获取日志集合，在面板中映射为操作步骤，支持按顺序回放样式修改过程，实现状态回滚与调试
数据传输中，单次传输最大消息负载如何？是否关注过传输性能影响？
负载情况：
- 优化前：基于浏览器插件方案，传输完整ElementTree，大文档场景下payload极大，影响性能
- 优化后：基于CDP协议，按协议规范分块传输，仅传输当前展开层级的节点（每次最多两层），payload显著减小，无性能压力
若没有CDP协议保障，大体积数据传输的优化方案是什么？
将JSON格式的大体积数据切割分块，通过ID标识传输顺序，接收端完整接收后拼接组装，再映射为可视化节点结构，避免单次传输过大导致的性能问题
React中JSX语法如何一步步渲染成对应的DOM？
JSX本质：UI语法糖，底层编译为createElement或_jsx方法调用
渲染流程：
- 转译：Babel将JSX解析为抽象语法树（AST），映射为React元素（虚拟DOM节点）
- Fiber树构建：React将虚拟DOM转换为Fiber树（链表结构，便于Diff计算）
- Diff算法：计算Fiber树与真实DOM的差异，标记Placement、Update、Delete等操作
- Commit阶段：统一执行差异更新，调用浏览器DOM API构造完整DOM树
React中状态变更时，是否每次都会执行完整的DOM更新？
不会，React通过Diff算法计算DOM差异，仅对变化的部分进行更新：
流程：状态变更触发组件重新渲染，生成新的虚拟DOM，与旧虚拟DOM进行Diff对比，收集差异操作，最终在Commit阶段仅执行差异更新，避免全量DOM操作
React列表场景中，状态变更时Diff算法有什么不同？如何优化？
- 列表Diff逻辑：与普通DOM节点Diff逻辑一致，通过对比节点类型、属性等识别差异
- 优化方案：为列表项添加key属性，React可通过key快速定位节点位置变化（如新增、删除、排序），避免不必要的节点销毁与重建，提升Diff效率
二面
飞书文档渲染引擎项目的核心技术点是什么？
项目背景：飞书文档原基于DOM渲染，浏览器把控完整渲染流程，大文档场景下因评论、工具栏等元素存在性能卡顿问题，且渲染流程不可干预，故研发Canvas渲染引擎，自主把控layout和paint流程
核心技术栈：
- 原生TS开发，内部有自定义DSL原语，适配Vue开发环境，降低迁移成本
- 配套基于Canvas的组件库及Duetos工具
- 提供类似Vue Hooks的方法，优化开发体验
技术难点与解决方案：需搭建完整Canvas生态，包括组件库和调试工具；Duetos工具实现DSL层级结构可视化，提供elements面板，支持hover查看节点及样式、直接修改样式无需热重载，还可扩展内部插件工具
飞书文档渲染引擎除卡顿优化外，在秒开、滚动等其他性能方面有哪些优化措施？
- 场景化优化：滚动场景通过两张KVOS，以贴像素点方式优化；针对编辑、白屏等场景封装自定义DSL，业务使用时可直接享受优化
- 轻量化设计：明确服务于文档场景，裁剪W3C标准，简化API、样式及DSL，在满足使用需求的基础上扩展内部原语和style，使引擎更轻量
飞书文档项目中开发工具的使用场景有哪些？
- 可视化调试：提供elements面板，展示DSL的层级结构、节点属性及样式，支持hover定位节点，方便开发调试
- 高效开发：支持在工具面板直接修改样式并实时生效，无需修改代码后热重载；可扩展内部插件工具，完善生态
腾讯低代码平台项目的核心架构是什么？
项目用途：服务于腾讯充值等业务的活动落地页搭建，如王者荣耀抽奖活动
核心架构：
- 基于腾讯内部低代码渲染引擎，以Schema为核心，包含编辑器和渲染器两大模块
- 编辑器提供编辑能力，可通过插件扩展业务逻辑
- 渲染器在H5场景通过运行时Renderer渲染，小程序场景因不支持动态编码，采用Tel做跨端兼容，提供CLI能力出码为静态化小程序代码包
组件体系：基于内部Schema和组件库，封装活动、店铺、商城等上层素材库组件
腾讯低代码平台项目中如何做包体积优化？
- 路由优化：启用路由懒加载，避免首屏加载不必要资源
- 依赖优化：
- 通过webpack插件分析模块依赖，将Vue DOM、Redom Editor等无需打包的资源改为External方式，通过CDN引入
- Lodash、eCharts从全量引入改为按需引入
- 统一内部组件库，减少重复包体积
小红书前端的跨端解决方案是什么？
主要有两种核心方案：
- 类RN方案
- 前端编写描述语言，通过DSL下发到端上后由Native渲染（类似腾讯光子黑皮方案）
小红书前端的上线流程及相关规范是什么？
遵循研发流程规范：
- 代码变更需经过code review
- 通过流水线检测语法问题、编译风险
- 打包后会校验上线内容一致性
- 存在变更审批流程，高峰期审批更严格
小红书是否有泳道环境或类似方式隔离不同版本？
通过分支管理实现版本隔离：
- 每个上线版本对应一个release分支
- 新功能先合并到主分支，发布时创建Revision
- bug修复在release分支起bug fix分支，修复后合并到release分支并Cherry-Pick到主分支，实现双写，避免版本依赖冲突
Last updated on