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 时请附上:变更背景与解决方案、关联任务或问题、影响的页面或模块、手工验证步骤;涉及界面改动时,需补充截图或录屏。 | ... | ... |
-
Please register or login to post a comment