网易雷火全栈一面凉经：UniApp 多端与 AI 知识库

《面试题目》

1. 请做一下自我介绍，并介绍你在实习项目中负责的内容。
2. UniApp 的多端适配是怎么处理的？平台适配层如何抽象？
3. rpx 在 H5 也能使用，为什么还要单独处理 H5 样式？
4. H5 和小程序是否维护两套样式？公共样式修改后是否需要两端分别调整？
5. 项目的 H5 主要面向 PC 端还是移动端？
6. H5 和微信小程序的登录链路是否相同？
7. 微信小程序跳转第三方页面时，需要进行哪些配置？
8. 你们的业务是独立小程序、子页面，还是原有小程序中的分包？
9. 小程序主包和分包分别是怎样下载的？为什么需要分包？
10. 用户第一次进入分包时可能出现白屏，有哪些优化方法？
11. 小程序能否提前下载分包？preloadRule 应该如何使用？
12. 用户端的商品搜索做了哪些优化？搜索结果是否使用缓存？
13. 使用中文输入法时，文字尚未确认会不会触发搜索？应该怎么处理？
14. 连续发起多个搜索请求时，旧请求晚返回并覆盖新结果的问题如何解决？
15. 长列表具体做了哪些渲染性能优化？
16. AI 知识库如何区分简单请求和复杂请求？
17. 如何根据置信度决定直接回答、进入完整工作流或返回证据不足？
18. 用户重复提问时是否会命中缓存？命中后还会不会执行完整 RAG 流程？
19. 如何根据问题复杂度动态控制模型调用次数？多个子问题如何拆解？
20. 在真实项目中，你如何使用 AI 完成需求拆解、代码生成、测试和 Review？
21. 你采用直接 Coding、Prompt 驱动还是 SDD？文档分别在哪些阶段产出，如何提供给 AI？
22. AI Review 的判断依据是什么？如何验证 AI 生成的代码和测试是否可信，哪些环节必须人工审核？

《参考解析》

UniApp 多端适配与平台适配层

适配的基本手段有三层。第一层是条件编译，用 #ifdef MP-WEIXIN、#ifndef H5 这类注释把平台专属代码隔离在同一个文件里；第二层是 API 归一化，uni. 系列 API 在编译期映射到各端原生能力，差异大的能力（登录、支付、分享、存储）封成统一的适配层接口，业务只依赖接口；第三层是样式与组件差异，原生组件在小程序里的层级和样式限制、H5 的响应式与最大宽度约束都不一样，需要用变量加覆盖文件的方式管理。判断一套样式还是两套的标准是差异比例：公共部分沉到共享变量和原子类，只有真正平台专属的部分才分文件维护，否则「改一处要改两处」的维护成本会失控。

rpx 与 H5 样式的特殊处理

rpx 是按 750 设计稿宽度等比换算的单位，小程序里由渲染层换算成物理像素，H5 里 UniApp 会把它换算成 vw 或 rem 之类。之所以还要单独处理 H5 样式，是因为换算只解决了「等比例缩放」这一个问题：PC 端浏览器窗口可以非常宽，等比放大会让内容被拉得巨大，需要限制最大宽度、加断点、把导航和列表从移动端布局切换成多列；而小程序永远是手机屏，没有这些问题。所以 H5 要额外处理响应式断点、交互差异（hover 与点击）和滚动行为。

H5 与小程序的登录链路

不相同。小程序走 wx.login 拿临时 code，后端用 code 加 appid/secret 换 openid 和 session_key，再签发自己的登录态；H5 通常走公众号或开放平台的 OAuth 授权，或者手机号加验证码、扫码登录。两者用户标识体系也可能不同（openid、unionid、手机号），所以后端要有一套账号绑定与合并逻辑，前端则要处理登录态过期后的静默重登。

小程序跳转第三方页面需要什么配置

跳其他小程序要用 wx.navigateToMiniProgram，需要在 app.json 里声明 navigateToMiniProgramAppIdList（有数量上限），且目标小程序要允许被跳转，用户侧会弹确认。跳 H5 页面用 web-view 组件，域名必须先在微信公众平台配置业务域名并上传校验文件，且只有企业主体才能配置。跳 App 用 wx.navigateToMiniProgram 之外的开放能力（如 wx.openUrl 或 App 互联），同样需要平台侧登记。这些配置项漏一个，真机上就是白屏或直接失败。

分包加载与白屏优化

主包在启动时下载，分包在用户真正进入时才下载，所以第一次进分包页会出现等待甚至白屏。优化手段：一是把非首屏资源全部挪到分包，压小主包体积（微信主包上限 2 MB）；二是用 preloadRule 预下载，在 app.json 里对主包的关键页面配置预下载的分包列表，可以指定只在 WiFi 下预载，注意预下载总量也有上限；三是分包异步化，允许跨分包引用组件和 JS；四是开按需注入（"lazyCodeLoading": "requiredComponents"）减少启动时要注册的组件；五是前端侧用骨架屏和 loading 兜住等待感。

中文输入法与并发搜索的坑

中文输入法在拼音还没上屏时也会触发 input 事件，如果直接拿去搜索，用户输入「shouji」的中间态也会发请求，既浪费流量又会出现奇怪的联想结果。处理方式：监听 compositionstart 和 compositionend，在组合输入期间不发请求，compositionend 后再触发；或者判断 event.isComposing 直接跳过。并发覆盖问题靠三件事一起解决：输入防抖（200 到 300 毫秒），给每个请求打自增序号并只接受最新序号的结果，以及用 AbortController 主动取消上一个在途请求。搜索结果加一层 LRU 缓存，key 用归一化后的关键词（去空格、统一大小写），能明显减少重复请求。

长列表的渲染优化

首要是虚拟列表：只渲染视口内加少量缓冲区的节点，滚动时复用节点，这样 DOM 数量与数据总量解耦。其次是分页与触底加载，避免一次拿几千条。在小程序里 setData 是最大的性能瓶颈，要只传变化的字段、合并多次 setData、避免在滚动回调里同步调用 setData（改用 recycle-view 或自己维护可视区）。另外列表项的 key 要稳定，图片要懒加载加占位，复杂计算用 computed 缓存。

AI 知识库的请求分流与置信度策略

分流放在检索前：先做意图识别和复杂度判断（规则加小模型分类），简单的单跳事实问题走短路（直接检索加一次生成），复杂的多跳问题才进完整工作流（拆子问题、多轮检索、调用工具）。置信度主要来自检索侧的证据强度（向量相似度、rerank 分数、命中片段数量）和生成侧的自评（答案是否有引用支撑、是否与检索内容矛盾）。三档处理：高置信直接回答并附引用来源；中置信进完整工作流多找几轮证据；低置信或检索为空就明确说证据不足，给出人工入口，不要硬答。阈值必须靠离线评测调，看的是误答率和转人工率的平衡，不能凭感觉设。重复提问可以命中语义缓存直接返回，但缓存要带 TTL，并且把用户画像和权限维度纳入 key，否则会串数据；命中缓存后不需要再跑完整 RAG。

用 AI 做开发与 AI Review 的可信度

推荐流程是：需求拆解阶段让 AI 出方案草稿和边界清单，人来拍板；然后写清 spec、接口和测试用例（用例先行，AI 生成主体、人补边界）；编码分小步进行，每步人 review 再继续；自动跑测试、lint 和类型检查。文档在三个阶段产出——需求阶段出 spec、设计阶段出接口与数据模型、编码阶段出变更说明，都以文件形式放进仓库供 AI 检索，这也是 SDD（文档驱动）相对直接 Coding 的优势。AI Review 的判断依据应该是可验证的东西：是否有测试覆盖、是否违反既有约定、边界与错误处理是否处理、有没有安全隐患，而不是「看起来对不对」。有几类必须人工审核：权限与鉴权、资金与数据一致性、对外接口兼容性、架构决策。验证 AI 生成的测试是否可信，要警惕它写出「跟随实现」的断言——实现改错测试也跟着改，可以用变异测试和人工检查关键断言来兜底。