微信小程序页面迁移校验之前 P5任务处理之前

apps/miniprogram - 副本/doc/howtodo.md

@@ -0,0 +1,97 @@
+
+
+1) 迁移前审计与准备（强烈建议先跑这个）
+你是一名资深微信小程序前端架构师+CSS布局专家。我要把一套 Web 页面（HTML/CSS/少量JS）迁移为“原生微信小程序”（WXML/WXSS/JS/JSON），要求结构与样式细节还原度尽可能高。
+
+输入（我将分段提供）：
+- 页面HTML（可含多页面）
+- 全量CSS（含reset/公共样式）
+- 资源清单（图片/字体/图标svg等路径）
+- 若有：目标效果截图/设计稿
+
+请先不要写最终代码，先做《迁移审计与准备报告》，输出必须包含以下部分，并使用清晰的编号标题：
+
+A. 页面结构清单：列出每个页面的主要区域（header/hero/list/card/footer等）及建议组件化边界（哪些抽组件、哪些保留页面内）
+B. CSS复杂度审计：列出会影响小程序还原的高风险点（如 position: sticky、复杂选择器、伪元素、滤镜、背景混合、滚动容器、字体/line-height差异、overflow裁切、z-index层叠等），并给出在小程序里的替代策略
+C. HTML→WXML映射规则：语义标签映射、事件绑定映射、表单控件映射、列表渲染（wx:for）策略
+D. CSS→WXSS映射规则：单位策略（px→rpx换算方案、断点策略）、选择器扁平化策略、样式隔离策略（页面/组件wxss组织）、必要时是否引入原子化类（如仅用基础class，不引第三方）
+E. 资源处理：图片/字体/图标（svg转png或iconfont方案）、2x/3x图、网络图片策略、包体与分包建议
+F. 产物目录规划：给出建议的最终目录树（pages/、components/、styles/、assets/），并说明每个文件职责
+G. 最小补充信息清单：如果缺少信息，列出“为了高还原必须补充的最小信息”（例如：页面宽度基准、设计稿字号、是否允许自适应裁切等）
+
+输出要求：表格+要点并存；每个高风险点给出“原因 + 影响 + 处理方案 + 验收方式”。
+
+2) 生成第一版代码（要求目录树+逐文件输出）
+基于你刚才的《迁移审计与准备报告》，现在开始生成可运行的小程序第一版代码（优先保证结构与样式还原、其次是交互完整度）。
+
+硬性要求：
+A.输出完整目录树（含 pages、components、styles、assets）
+B.按文件逐个输出内容：.wxml / .wxss / .js / .json
+C.样式组织：公共样式抽到 styles/common.wxss（或等价方案），页面只放页面差异
+D.尽量避免依赖第三方库；如必须引入，必须说明理由、替代方案、以及如何降低包体影响
+E.对所有“Web里有但小程序不完全支持”的效果：必须写清替代实现与预期差异
+
+我将提供：
+- <PAGE_NAME_1> 的HTML：<<<...>>>
+- 全量CSS：<<<...>>>
+- 可选：截图/设计稿要点：<<<...>>>
+
+请输出：
+I. 目录树
+II. 逐文件代码（从 app.json/app.wxss/app.js 开始）
+III. 编译与运行说明（微信开发者工具中需注意的设置项）
+IV. 第一版“已知差异清单”（按严重度排序：P0/P1/P2）
+
+3) 高保真样式“对齐增强”专用提示词（第二轮开始用）
+现在进入“高保真样式对齐”阶段。目标：在不破坏现有结构的前提下，把视觉细节尽量贴近 Web/设计稿。
+
+我会提供：
+- 当前小程序代码片段（相关 wxml/wxss）
+- Web 参考（对应HTML/CSS片段）或截图差异描述
+- 具体差异点列表（例如：间距、对齐、字体、行高、圆角、阴影、图片裁切、列表间距、按钮高度等）
+
+你的任务：
+A. 对每个差异点，给出：根因判断（布局/单位/行高/盒模型/层叠/渲染差异）+ 最小修改方案 + 修改后风险
+B. 输出“补丁式修改”：只给出需要改动的文件与改动段落（像 git diff 一样），不要整文件重贴
+C. 给出验收步骤：在微信开发者工具与真机预览分别怎么验证
+
+约束：
+- 优先使用 flex/盒模型的确定性方案，尽量减少依赖“碰运气”的魔法数
+- px→rpx 的换算要统一，严禁同一类间距一会儿 rpx 一会儿 px
+4) 结构还原与组件化质量提升（防止“越改越乱”）
+请对当前小程序实现做一次“结构与可维护性重构”，目标是在不改变 UI 效果的情况下，提高组件化与样式可控性，从而提升后续对齐效率。
+
+输出必须包含：
+A.现状问题清单（重复样式、选择器过深、耦合、命名不一致、难以复用的结构）
+B.组件拆分方案（组件名、props、slot策略、事件、数据流）
+C.样式治理方案（BEM/命名规范、公共变量、间距/字号/圆角/阴影的设计token化）
+D.重构后的目录树
+E.逐文件补丁（diff风格），并说明每个改动为何不影响UI
+
+约束：不引第三方UI库；不改变页面路由与业务数据接口（若有）。
+
+
+5) 细致对比与验收清单（你要的“对比更细致”）
+请为本次迁移输出《像素级对比与验收清单》，用于我逐项对照 Web 版本与小程序版本。
+
+要求：
+- 按页面输出（每页一个小节）
+- 每页包含：布局结构、间距系统、字体系统、颜色、边框/圆角、阴影、图片裁切、交互态（hover/active/disabled等在小程序里等价态）、滚动与吸顶、列表与空状态
+- 每条验收项必须可操作：说明“怎么看”“合格标准是什么”“常见失败表现是什么”
+- 额外输出《差异追踪表》：字段包括【差异描述｜截图/位置｜严重度P0/P1/P2｜可能原因｜建议修复方案｜修复代价｜回归点】
+
+输出用表格为主，保证我可以直接复制到文档里当验收用例。
+
+
+6) 编译报错/真机差异快速修复（把 Opus 当“修复代理”）
+你是微信小程序调试与兼容性专家。我会贴出：
+- 微信开发者工具编译报错/警告日志
+- 真机预览与模拟器表现差异描述
+- 相关代码片段
+
+请你：
+A.先定位根因（按概率排序列出 1~3 个最可能原因）
+B.给出最小修复补丁（diff风格）
+C.给出回归测试点（防止修A坏B）
+D.如果是基础库兼容问题，说明需要的最低基础库版本或降级方案
+