hookehuyr

docs: 更新仓库指南以反映实际业务骨架

补充项目功能概览,详细说明各核心模块职责与交互关系,重点描述首页分发、底部导航、资讯链路、支付流程和授权机制。更新项目结构说明,明确各目录的实际用途而非模板化描述。细化构建调试、Mock使用、授权支付链路约定等章节,确保文档与当前实现保持一致。
Showing 1 changed file with 24 additions and 3 deletions
1 # 仓库指南 1 # 仓库指南
2 2
3 +## 项目功能概览
4 +当前项目不是一个只有单页示例的小程序壳,而是一套已经串起“首页内容分发 + 动态底部导航 + 资讯列表/详情 + WebView 容器页 + 授权 + 微信支付桥接”的业务骨架。
5 +
6 +- 首页主链路在 `src/pages/index/`,通过 `src/api/index.js` 拉取 banner、宫格导航和图片入口;点击后要么跳内部页面,要么通过 `src/utils/webview.js` 组装参数进入通用 `WebView` 容器。
7 +- 底部导航不是写死在页面里的,核心在 `src/components/AppTabbar.vue``src/stores/tabbar.js``src/api/tabbar.js``src/utils/tabbar.js`。应用启动时会预加载 tabbar 配置,`application``mine` 现在都是“按接口返回地址承接 WebView”的容器页。
8 +- 资讯演示链路在 `src/pages/message/``src/pages/message-detail/`,既是当前业务页,也是本地 mock 是否支持“列表 -> 详情 -> 已读状态变化”的验证入口。
9 +- 支付相关目前有三类页面:`src/pages/pay-test/` 用于手工调试授权和支付参数;`src/pages/pay-confirm/` 是用户确认金额后点击支付的正式按钮页;`src/pages/pay-bridge/` 是给 H5/WebView 调起小程序支付用的桥页,负责自动授权、拉起支付、展示结果并返回上一页。
10 +- `src/pages/webview-preview/` 是通用外链承接页,`src/pages/application/``src/pages/mine/`、首页外链入口都会复用这类能力;`src/pages/map-guide/` 是固定地图签到 H5 页;`src/pages/auth/` 是统一授权页,不能绕过。
11 +- `src/pages/mine-backup/` 目前更适合作为旧版“我的”页视觉与交互备份参考,不应默认当作线上主链路去扩展新业务。
12 +
3 ## 项目结构与模块组织 13 ## 项目结构与模块组织
4 -源码位于 `src/`。路由页面放在 `src/pages/<page>/`,每个页面通常包含 `index.vue``index.less``index.config.js`。通用组件放在 `src/components/`,复用逻辑放在 `src/composables/``src/hooks/`,接口封装放在 `src/api/`,公共工具放在 `src/utils/`,全局状态放在 `src/stores/`。构建配置集中在 `config/`,应用入口为 `src/app.js``src/app.config.js` 14 +源码位于 `src/`,应用入口为 `src/app.js``src/app.config.js`。当前目录分工建议按下面理解,而不是只把它当成普通 Taro 模板:
15 +
16 +- `src/pages/`:页面路由主目录。当前重点页面包括 `index``message``message-detail``application``mine``pay-test``pay-confirm``pay-bridge``webview-preview``map-guide``auth`;其中 `application` / `mine` 更偏 WebView 容器,`pay-bridge` 更偏桥接页,`mine-backup` 是备份页。
17 +- `src/components/`:通用组件目录。当前最关键的是 `AppTabbar.vue``PosterBuilder/`、二维码组件、时间选择器等属于可复用能力模块。
18 +- `src/composables/`:组合式业务逻辑目录。`useWechatMiniPay.js` 是当前支付链路核心,和页面解耦较强;离线预约缓存相关逻辑也集中在这里。
19 +- `src/hooks/`:较轻量的通用 hooks,目前主要是 `useGo.js` 这类导航辅助。
20 +- `src/api/`:接口封装层。`fn.js` 是统一返回格式与 mock 接入的总入口,`index.js``message.js``tabbar.js``wx/pay.js` 分别承接首页、资讯、底部导航、微信支付等接口。
21 +- `src/mock/`:本地 mock 体系。目录拆分规则是 `index.js` 统一入口、`modules/` 放 handler、`shared/` 放公共解析能力、`stores/` 放有状态 mock 数据、`fixtures/` 放静态样本。
22 +- `src/utils/`:公共工具层。当前高频核心文件是 `authRedirect.js``request.js``config.js``webview.js``tabbar.js``wechatPay.js`;改动授权、环境、WebView 路由或支付时优先先看这里。
23 +- `src/stores/`:Pinia 状态目录。当前重点是 `tabbar.js`(底部导航配置)和 `router.js`(授权回跳来源页),其他 store 多为基础能力或历史保留。
24 +- `src/assets/``src/constants/`:分别承接静态资源和常量;其中 `src/constants/` 目前较轻,新增共享枚举或键名时再往这里收。
25 +- `config/`:构建与环境配置目录,`dev.js` / `prod.js` 控制 `API_RUNTIME_ENV`,不要把环境切换逻辑重新分散回页面层。
5 26
6 ## 构建、调试与开发命令 27 ## 构建、调试与开发命令
7 使用 `pnpm install` 安装依赖。开发微信小程序时运行 `pnpm dev:weapp`,调试 H5 时运行 `pnpm dev:h5`。生产构建常用 `pnpm build:weapp`,如有多端需求,也可使用 `pnpm build:h5``pnpm build:alipay` 等命令。提交前必须执行 `pnpm lint`,当前仓库已配置的自动检查主要就是 ESLint。 28 使用 `pnpm install` 安装依赖。开发微信小程序时运行 `pnpm dev:weapp`,调试 H5 时运行 `pnpm dev:h5`。生产构建常用 `pnpm build:weapp`,如有多端需求,也可使用 `pnpm build:h5``pnpm build:alipay` 等命令。提交前必须执行 `pnpm lint`,当前仓库已配置的自动检查主要就是 ESLint。
...@@ -20,9 +41,9 @@ Mock 逶ョ蠖穂ケ滓怏譏守。ョ蛻キ・啻src/mock/index.js` 蜿ェ蛛夂サ滉ク蜈・蜿」蜥悟蜿托 ...@@ -20,9 +41,9 @@ Mock 逶ョ蠖穂ケ滓怏譏守。ョ蛻キ・啻src/mock/index.js` 蜿ェ蛛夂サ滉ク蜈・蜿」蜥悟蜿托
20 ## 授权与支付链路约定 41 ## 授权与支付链路约定
21 授权逻辑的核心在 `src/app.js``src/utils/authRedirect.js``src/utils/request.js``src/pages/auth/index`。应用启动时会优先尝试静默授权,`sessionid` 统一写入 Taro 本地缓存,并由请求拦截器动态注入到请求头;接口返回 `401` 时,会先尝试 `refreshSession` 静默续期并重放原请求,失败后再降级跳转授权页。因此除非明确重构整条链路,否则不要随意改动 `sessionid` 的存取方式、`saveCurrentPagePath` / `returnToOriginalPage` 的回跳机制、`navigateToAuth` 的防重逻辑,也不要跳过 `src/pages/auth/index` 直接在业务页硬编码授权流程。若修改分享进入、启动授权、401 重试或来源页回填逻辑,需至少手工验证一次“未授权进入页面 -> 自动或手动授权 -> 成功回跳原页面”的完整闭环。 42 授权逻辑的核心在 `src/app.js``src/utils/authRedirect.js``src/utils/request.js``src/pages/auth/index`。应用启动时会优先尝试静默授权,`sessionid` 统一写入 Taro 本地缓存,并由请求拦截器动态注入到请求头;接口返回 `401` 时,会先尝试 `refreshSession` 静默续期并重放原请求,失败后再降级跳转授权页。因此除非明确重构整条链路,否则不要随意改动 `sessionid` 的存取方式、`saveCurrentPagePath` / `returnToOriginalPage` 的回跳机制、`navigateToAuth` 的防重逻辑,也不要跳过 `src/pages/auth/index` 直接在业务页硬编码授权流程。若修改分享进入、启动授权、401 重试或来源页回填逻辑,需至少手工验证一次“未授权进入页面 -> 自动或手动授权 -> 成功回跳原页面”的完整闭环。
22 43
23 -支付链路给业务侧的精简描述可以理解为:`map-demo` 的 H5 页面先通过项目里的 `pages/webview-preview/index` 进入小程序 `WebView`,当 H5 侧需要发起支付时,再把 `order_id` 传给小程序里的 `pages/pay-bridge/index`;桥页负责检查授权状态、必要时补做静默授权,然后通过 `src/composables/useWechatMiniPay.js` 调用 `/srv/?a=pay` 向后端换取微信支付参数,最后由小程序侧执行 `Taro.requestPayment` 拉起正式支付。支付完成后,桥页会根据成功、取消、失败三种结果给出状态提示,并自动返回上一页,回到原来的 `WebView/H5` 场景。 44 +支付链路现在至少有两种入口,不要再把它理解成只有一个测试桥页。第一种是小程序内直接支付:业务页把 `order_id`、金额等参数带到 `src/pages/pay-confirm/index.vue`,用户确认后通过 `src/composables/useWechatMiniPay.js` 调用 `/srv/?a=pay`,再由小程序侧执行 `Taro.requestPayment`。第二种是 H5/WebView 发起支付:外部页面先进入 `pages/webview-preview/index` 或 tabbar 对应的 WebView 容器,再把 `order_id` 传给 `pages/pay-bridge/index`;桥页负责检查授权状态、必要时补做静默授权、拉起支付、展示成功/取消/失败结果,并自动返回上一页。
24 45
25 -仓库实现上,测试/桥接链路核心在 `src/composables/useWechatMiniPay.js``src/api/index.js``src/pages/pay-test/index.vue``src/pages/pay-bridge/index.vue`;另一条是通用支付封装,位于 `src/utils/wechatPay.js``src/api/wx/pay.js`,通过 `pay_id` 调用 `/srv/?a=icbc_pay_wxamp`。修改支付逻辑时务必先确认当前页面接的是哪一条接口链路,不要混用 `order_id``pay_id`,也不要在未拿到后端有效支付参数时直接调用 `requestPayment`。涉及 H5/WebView 唤起支付时,应优先保持 `pages/pay-bridge` 的桥接职责与返回参数约定稳定;涉及支付结果处理时,需区分成功、取消、失败三类状态,并至少在微信开发者工具或真机中验证一次“授权状态检查 -> 拉起支付 -> 返回结果展示/回跳”的流程。 46 +仓库实现上,共享支付能力核心在 `src/composables/useWechatMiniPay.js``src/api/index.js`;调试入口在 `src/pages/pay-test/index.vue`,正式确认页在 `src/pages/pay-confirm/index.vue`,H5 桥接页在 `src/pages/pay-bridge/index.vue`。另一条是通用支付封装,位于 `src/utils/wechatPay.js``src/api/wx/pay.js`,通过 `pay_id` 调用 `/srv/?a=icbc_pay_wxamp`。修改支付逻辑时务必先确认当前页面接的是哪一条接口链路,不要混用 `order_id``pay_id`,也不要在未拿到后端有效支付参数时直接调用 `requestPayment`。涉及 H5/WebView 唤起支付时,应优先保持 `pages/pay-bridge` 的桥接职责与返回参数约定稳定;涉及小程序内直接支付时,应优先保持 `pages/pay-confirm` 的“展示金额 -> 用户点击 -> 调用共享支付能力”职责单一。无论改哪条链路,都需要区分成功、取消、失败三类状态,并至少在微信开发者工具或真机中验证一次“授权状态检查 -> 拉起支付 -> 返回结果展示/回跳”的流程。
26 47
27 ## 提交与合并请求规范 48 ## 提交与合并请求规范
28 当前 Git 历史以简短中文提交为主,例如 `初始化觉林寺小程序项目`。后续提交信息也请保持中文、简洁、祈使语气,并聚焦单一改动。提交 PR 时请附上:变更背景与解决方案、关联任务或问题、影响的页面或模块、手工验证步骤;涉及界面改动时,需补充截图或录屏。 49 当前 Git 历史以简短中文提交为主,例如 `初始化觉林寺小程序项目`。后续提交信息也请保持中文、简洁、祈使语气,并聚焦单一改动。提交 PR 时请附上:变更背景与解决方案、关联任务或问题、影响的页面或模块、手工验证步骤;涉及界面改动时,需补充截图或录屏。
......