检查小程序页面重点、导航、输入、加载、结果与异常恢复，适用于预约、填报、查询和审批等业务流程。
## 任务目标 请验收当前微信小程序的业务流程与界面体验，以真实用户角色和本次任务目标为依据。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 验收流程：从当前会话涉及的页面或已提供截图识别用户要完成的主要任务；没有流程清单时沿现有页面入口、主要按钮及结果页梳理一条真实任务路径。 小程序或页面资料：使用现有页面代码、截图、可访问预览、路由配置、接口状态及已有品牌样式，自动梳理角色可见的业务步骤。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 追踪首页、分享、扫码和历史入口的直达路径，以及返回、取消、退出后的数据状态。 - 核对表单字段、必填与默认值来源，检查成功、失效、无权限及失败恢复的真实接口依据。 - 检查主要操作、中文反馈、键盘遮挡、菜单预留、长文本和字体放大表现。 ### 可采用的默认处理 - 默认只读验收并给具体调整；明确要求修复时再实施对应页面变更，不自动改变办理顺序。 - 沿用现有业务术语与视觉规范；缺规范时保持主任务清楚、操作集中、状态可理解，不补造宣传信息。 - 只有截图时仅判断可见布局及文案，导航、输入保留和提交安全分别列待交互核验。 ### 必须有依据的事项 - 无法确定办理角色、业务完成条件或关键字段的真实必要性，不能自行删步骤、代填事实或判定流程正确。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 只有截图时按页面给可见问题、用户影响和具体调整，并补可执行的异常恢复验收步骤。 - 没有可运行小程序时由路由和接口状态整理任务路径及测试矩阵，区分静态证据和待真机交互。 ## 执行要求 按微信内移动业务流程进行验收，页面的政企风格与中文业务文案遵循当前项目要求，不套用统一视觉模板。 1. 逐页指出用户当前要做什么、完成后去哪里以及如何返回。检查每页是否突出一个主要业务目标，导航和按钮是否能反映真实流程，清理无关宣传内容与重复引导，避免让用户在表单中被其他推荐打断。 2. 检查返回、取消和退出后的数据状态，覆盖从分享、扫码及历史入口直接进入页面。页面应能说明当前业务对象和进度，不能假设用户必定从首页按固定顺序进入。 3. 审查所有输入项是否确有必要，能选择的值优先提供明确选项，默认值必须有业务依据。字段标签、单位、格式和必填条件清晰可见，不能为了减少输入而未经用户理解就代填关键业务事实。 4. 根据操作范围设计加载和结果反馈：局部更新尽量原位反馈，耗时操作说明当前状态。错误需要足够明确且能够继续处理，不能一闪而过；成功页应说明已经完成的业务以及合适的下一步。 5. 验收网络失败、无数据、校验失败、记录失效和权限不足时的恢复路径。表单错误定位到相关项目，保留仍有效的输入；重试、修改和返回动作应与真实服务端状态匹配，避免造成重复提交。 6. 检查点击区域、控件间距、键盘遮挡、长文本、字体放大和官方菜单预留区域。保持同类组件和状态表达一致，使用真实业务内容检验对齐与换行，避免大面积装饰、花哨动效和没有含义的数据卡片。 ## 交付与验收 输出：按流程排序的问题清单，每项包括页面、触发操作、用户影响、具体调整和验收条件；另给完整任务路径与异常恢复表。已有代码且用户明确要求修复时，实施必要修复并验证，只有截图时明确无法确认的交互，不把静态外观审查当成流程全部通过。 ### 本条完成检查 - 按实际任务顺序输出问题、页面、触发、影响和验收条件，不用笼统审美评价替代业务问题。 - 覆盖直达、返回、取消、权限不足、记录失效和提交失败的恢复路径，确认合理输入可保留。 - 单列点击、键盘、长中文、字体放大及菜单区域检查结果，只有静态材料不得报全流程通过。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [腾讯微信《微信小程序设计指南》](https://developers.weixin.qq.com/miniprogram/design/)
定义微信小程序组件的属性、插槽和样式入口，处理组件注册、样式污染及不同页面的复用问题。
## 任务目标 请根据本次要求，将小程序中的重复业务界面封装为可复用组件，或审查已有组件的边界与样式隔离。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 组件目标：优先审查当前页面引用的目标组件；若对话明确要求封装重复界面，则从真实使用页面识别共同职责后实施，不凭相似外观创建通用组件。 组件或使用页面：读取组件及调用页面的 JSON、WXML、WXSS、脚本、事件监听和已有运行配置，从实际工程识别原生或跨端框架。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 对照真实调用场景确定数据所有者、内部状态、业务差异及是否存在稳定复用职责。 - 核对 usingComponents 路径、properties、事件载荷、插槽与 multipleSlots 配置。 - 检查 styleIsolation、外部样式类、虚拟节点及渲染器支持，跨端工程同时追查生成代码。 ### 可采用的默认处理 - 没有明确封装或修复要求时只读审查；实施时保持原有属性、事件和页面行为兼容。 - 优先现有隔离方式与明确的外部样式入口，不为局部问题全局开放样式共享。 - 仅有一个真实场景时按独立职责判断是否值得封装，不虚构第二个页面或添加大量未来开关。 ### 必须有依据的事项 - 不同调用页面对属性、事件或内部状态职责存在冲突，无法在不改变业务的情况下确定通用契约。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 缺运行环境时交付组件契约、样式入口、可检查代码或修正片段及逐页验证步骤。 - 只有截图时先给稳定职责与差异清单，不凭截图承诺原生注册、插槽或渲染器兼容。 ## 执行要求 按微信原生组件的能力检查实现。使用跨端框架时，进一步核对生成代码和框架适配，不能直接照搬浏览器或 Vue 的样式规则。 1. 先列出组件必须完成的业务任务、调用方负责的数据与内部展示状态。比较多个页面的共同部分和真实差异，只抽取已经稳定的职责；不要把整张业务页面塞进一个参数繁多、难以理解的通用组件。 2. 检查页面及组件 JSON 中的声明，确认引用名称和实际路径一致。为属性建立名称、类型、默认值及空值约定，核对数据能否在当前环境传递；非法输入要有清楚的处理，不依赖隐式转换掩盖接口错误。 3. 按内容扩展需求选择默认插槽或命名插槽。需要多个插槽时核查 multipleSlots 配置，并说明每个插槽负责的区域及为空时的表现；业务事件的名称和返回字段应稳定且与调用方用法对应。 4. 按官方文档检查样式选择器及 styleIsolation 设置，识别页面样式穿透组件、组件污染其他页面和继承属性变化。不能为修好一个样式问题就全局开放共享，先定位实际受影响的类与节点。 5. 通用组件需要允许定制时，优先设计明确的外部样式类入口，并列出哪些外观允许调整。避免调用方依赖组件内部层级或未约定的祖先样式；若启用虚拟节点，检查根节点布局、class 与 style 的实际生效位置。 6. 在至少两个真实使用页面验证正常数据、空数据、长中文文本、禁用状态、插槽缺省和局部样式覆盖。对已声明支持的渲染器及基础库环境分别记录结果，检查事件次数和数据回传是否符合调用契约。 ## 交付与验收 输出：组件职责说明、属性与事件表、插槽和样式入口、组件实现及复用验收结果。没有运行环境时只给可检查的实现和验证步骤，标明兼容性待测；需求只出现一个使用场景时说明抽象依据，不虚构更多业务来证明组件通用。 ### 本条完成检查 - 明确组件职责、属性类型和空值、事件次数及载荷、插槽和允许调整的样式入口。 - 在真实使用页面验证空数据、长中文、禁用和局部覆盖；只有一个场景时说明限制，不假造复用证据。 - 分别记录已支持基础库和渲染器的结果，确认组件不污染相邻页面且回传数据符合调用方。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [腾讯微信《微信小程序：组件模板和样式》](https://developers.weixin.qq.com/miniprogram/dev/framework/custom-component/wxml-wxss.html)
审查微信小程序临时 code、服务端身份换取、自定义登录态及 session_key 保管，补齐业务授权联调。
## 任务目标 请对当前微信小程序及后端的登录链路进行实现或检查。不要提供真实密钥和用户个人数据。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 登录链路目标：沿现有 wx.login、登录请求、服务端换取身份和业务会话逐段检查；有明确新增登录或修复要求时在已确认账号关系内实施。 小程序或后端资料：查找登录模块、请求拦截器、后端认证入口、账号模型、会话配置和脱敏日志，使用已有安全配置位置，不要求粘贴真实密钥。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 追踪 wx.login 临时 code 的提交、服务端换取和自定义登录态签发，定位重复 code 与并发处理。 - 检查 AppID 配置来源、session_key 存放和响应日志，确认秘密不会下发到客户端。 - 读取微信身份与业务账号绑定、机构角色校验、会话失效及退出后的访问控制。 ### 可采用的默认处理 - 默认只读检查身份链路；明确实现时沿用现有认证和会话体系，不另造一套令牌或默认自动注册账号。 - AppID、AppSecret、用户身份及账号绑定不虚构；缺凭据时使用明确隔离的模拟响应验证状态处理。 - 客户端只提交必要凭证和选择意图，账号、租户和角色以可信后端授权为准，未知授权不得默认放行。 ### 必须有依据的事项 - 微信身份与业务账号的绑定、自动开户或机构授权规则无法确认，不能自行合并账号或赋予权限。 - 缺少真实 AppID 配置、服务端换取权限或可用测试账号时，只暂停对应真实登录联调，不伪造平台结果。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 仅有前端时交付可证实的 code、请求和登录态问题，列后端字段保管与授权核查点，不断言服务端安全。 - 没有联调条件时给完整时序、接口边界及重复 code、失效、停用和退出访问的隔离用例。 ## 执行要求 核对微信身份换取流程，并按项目需求明确业务账号绑定、租户授权、会话期限和退出策略。区分平台登录能力与业务系统自己的身份和权限规则。 1. 画清小程序、开发者服务器和微信服务之间的数据流。核对 wx.login 返回的临时凭证由谁提交、在哪里换取身份，以及后续业务请求使用哪一种自定义登录态，不能把微信临时凭证直接当成长期业务令牌。 2. 检查临时 code 的一次性使用约束，处理重复请求、凭证过期和登录并发。失败后按具体原因重新取得凭证，避免重复回放已经消耗的 code；前端只能根据服务端明确结果判断登录成功。 3. 核查服务端对 session_key 的保管，确认它不会进入小程序响应、前端存储、公开接口或业务日志。排查打包配置和错误输出中的服务端密钥，示例中统一使用占位符，不复制生产凭据到测试用例。 4. 明确微信身份与业务账号的对应关系，检查账号状态、机构和角色从可信服务端获取。客户端传入的用户编号或租户编号不能直接决定查询权限；切换机构时核对当前用户确有相应授权。 5. 按业务约定梳理登录中、已登录、会话失效、账号停用和退出后的页面行为。回到原业务页面时重新校验可操作状态，避免界面仍显示登录成功但接口持续失败；必要信息应在失败时保留以便继续操作。 6. 联调首次登录、再次登录、code 重复、微信服务失败、业务账号受限、会话过期和退出后访问。逐条核对请求、响应与界面状态，采用脱敏记录，确认异常没有泄露会话密钥或敏感堆栈。 ## 交付与验收 输出：登录时序、字段与保管位置、业务授权待确认项、必要实现及联调记录。无法访问服务端代码时明确审查边界，不凭前端界面断言权限安全；缺少会话约定时先指出所需决策，并完成官方登录步骤的可核对方案。 ### 本条完成检查 - 输出三方登录时序、字段流向和保管位置，区分微信身份与业务会话。 - 验证 code 重复、并发、平台失败、账号受限、会话过期及退出后访问，检查 session_key 不出现在客户端和日志。 - 分别记录静态审查、模拟测试与真实联调结果，未确认的账号和租户规则明确留待决策。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [腾讯微信《微信小程序：小程序登录》](https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/login.html)
规划微信小程序主包、业务分包及引用关系，检查启动路径、包体限制和分包加载失败后的体验。
## 任务目标 请为当前微信小程序制定或审查分包方案。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 分包规划目标：从现有 app.json 和可取得的构建体积报告检查主包压力与跨包引用；没有超限现象时先按真实启动和常用业务路径复核现有包归属。 工程或构建资料：读取小程序目录、app.json、TabBar、分享和扫码入口、公共资源引用、构建报告与主体及基础库配置。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 梳理启动页、TabBar 和直接进入页面，追踪脚本、组件及静态资源归属。 - 检查普通分包嵌套、跨包依赖及未被覆盖资源，识别独立分包和分包异步化是否真的需要。 - 从本次构建报告取得上传包体，结合可确认主体、发布渠道和当前官方规则核对限制。 ### 可采用的默认处理 - 默认审查并提供规划，不迁移文件或发布；明确重构时才按受影响页面实施最小包调整。 - 优先保留入口和公共依赖，未证实收益不引入独立分包或异步跨包能力。 - 缺体积报告时只给待测项和资源候选，不以源码目录大小或旧平台限额宣称可发布。 ### 必须有依据的事项 - 拟迁移页面承接外部分享或扫码，而入口兼容要求与初始化依赖无法确定，不能自行改变既有直达路径。 - 主体或发布渠道不明导致适用体积限制无法确认时，不给最终发布合规结论。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 只有目录和配置时交付页面归属、引用关系及最小调整草案，所有包体栏标待构建。 - 无法使用开发者工具时给构建取证与冷启动、分享直达、弱网首次下载的真机验收路径。 ## 执行要求 按微信小程序的包结构和发布要求审查方案。普通分包、独立分包和分包异步化的能力边界不同；所有限制需结合本次发布时的官方说明核实。 1. 从真实入口梳理启动页、TabBar 页面、常用业务路径和低频功能，列明每个页面依赖的脚本、组件及静态资源。优先让首个业务任务所需内容清晰可控，不以平均分配文件大小作为分包目标。 2. 对照 app.json 的分包配置核查目录，保证 TabBar 页面留在主包、分包根目录没有互相嵌套。找出未被分包覆盖而意外进入主包的资源，说明它们是公共依赖还是可以迁移的业务资源。 3. 检查普通分包之间的脚本、模板和资源引用，明确允许依赖主包的部分。若需要使用分包异步化或独立分包，单独核查该能力的版本与入口要求，不能只修改路径后假定运行时一定能找到依赖。 4. 使用构建报告记录主包、各分包和全部包体积，区分源码目录大小与最终上传体积。按当前主体和发布渠道核对平台限制，给出超限资源的具体位置及压缩、按需加载或去重方案，不沿用网上过时数字。 5. 检查冷启动、页面分享直达、扫码进入、TabBar 切换和从主包进入分包的路径。分包首次下载失败时给出用户可理解的反馈和重试入口，避免页面空白后只能退出小程序。 6. 在开发者工具构建后进行真机验证，覆盖弱网、首次下载、再次进入和升级后的资源加载。对于抽出的公共模块，重点回归初始化顺序与业务状态，记录体积和启动体验的实际变化。 ## 交付与验收 输出：页面与包归属表、依赖关系、配置改动、包体实测和进入路径验收表。没有构建结果时保留体积栏待测，不能把估算值作为可发布证明。涉及重构先列明受影响页面，保留已有业务入口和必要的兼容处理。 ### 本条完成检查 - 交付主包和各分包的页面归属、公共依赖及配置建议，确认 TabBar 与跨包引用规则。 - 分别记录主包、分包、总包实际上传体积及采用的当前限制依据。 - 验证启动、直达、TabBar、分包下载失败和再次进入；未构建或未真机验证不宣称可发布。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [腾讯微信《微信小程序：分包加载》](https://developers.weixin.qq.com/miniprogram/dev/framework/subpackages.html) - [腾讯微信《微信小程序：使用分包》](https://developers.weixin.qq.com/miniprogram/dev/framework/subpackages/basic.html)
定位微信小程序页面更新频率、组件规模和数据量问题，以真实交互和测量结果评估优化效果。
## 任务目标 请排查本次小程序页面或组件的卡顿、响应延迟或频繁更新问题。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 卡顿或更新现象：优先复现当前页面的慢操作；没有现象记录时，从 setData、高频监听、定时任务和接口回调识别重复更新候选，再按真实渲染数据验证。 页面或性能资料：查找目标页面脚本与模板、渲染器和基础库配置、现有性能记录及可运行的开发者工具环境。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 确认实际框架和渲染器，区分首次进入、滚动、输入、切页及后台更新的复现场景。 - 按同一操作统计更新次数、字段与体积，追踪模板真正依赖的数据及间接关联字段。 - 检查显示、隐藏和卸载生命周期中的定时器、监听及订阅，核对恢复显示后的业务状态。 ### 可采用的默认处理 - 默认只读定位并给最小优化片段，明确修复时才改更新逻辑；没有测量先给候选排序。 - 优先减少重复和无渲染用途数据，保留必要状态变化，不按固定次数或代码行数判定性能。 - 没有目标设备时记录当前可测条件，真机结论另列，不把模拟器流畅视为问题解决。 ### 必须有依据的事项 - 拟暂停或合并的更新关系到价格、倒计时、排序或操作对象有效性，而业务时效要求无法确认。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 有代码无设备时交付更新入口及负载清单、可疑重复路径和取证步骤。 - 只有现象时给同条件复现记录表，覆盖前后台切换和不同数据规模，不虚填帧率或提速。 ## 执行要求 先确认微信小程序当前使用的组件框架和渲染器，再决定适用的更新方式，不把其他平台的性能结论直接带入。 1. 复现问题并记录操作路径、数据量、设备和页面状态。区分首次进入慢、连续滚动卡顿、输入延迟与后台页面抢占资源；没有测量证据时先给假设排序，不凭代码行数判断性能瓶颈。 2. 查找数据更新入口，统计同一操作触发的次数、更新字段和数据体积，标记定时器、滚动监听、输入监听及接口回调。把必要刷新与重复刷新分开，检查连续调用能否在不改变业务顺序的情况下合并。 3. 对照模板实际使用字段检查 data，移出完全不参与渲染的数据，间接关联字段按当前能力处理。只更新变化字段，避免整体回传所有数据；保留能证明需要刷新的条件，不能为降低次数丢掉真实状态变化。 4. 检查高频变化是否发生在节点很多的大组件中，评估将倒计时、局部状态等拆到职责清楚的小组件。拆分前后比较真实更新开销，避免为了减少单个树规模而产生大量跨组件通信。 5. 检查页面进入后台、重新显示和卸载时的更新行为，处理不必要的定时任务与订阅。恢复显示时补齐业务状态，确保暂停无感刷新不会造成过期价格、错误倒计时或操作对象失效。 6. 使用平台可用的更新性能信息或开发者工具比较修改前后表现。在相同条件下复测滚动、输入、切页和恢复前台，记录耗时分布与操作反馈，同时验证列表数据、排序和业务状态没有变化。 ## 交付与验收 输出：瓶颈证据、更新调用清单、最小改动及前后对比。每项优化写明改变了什么、可能影响的业务和回归方法。无法取得真机数据时标记“待真机验证”，给出采集步骤，不编造帧率提升百分比，也不只凭模拟器流畅就宣布问题解决。 ### 本条完成检查 - 给出瓶颈证据、更新次数与字段体积，区别必要刷新和重复刷新。 - 如实施优化，在同条件比较更新开销，并回归列表、排序、倒计时和前台恢复状态。 - 记录真实设备、网络、数据量与耗时分布，明确未真机验证部分。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [腾讯微信《微信小程序：合理使用 setData》](https://developers.weixin.qq.com/miniprogram/dev/framework/performance/tips/runtime_setData.html)
