gxwebsoft
f986efce8c
- 调整 .env.development 中 VITE_API_URL 配置为正式接口地址 - 修复 ShopGoods.sectionIds 字段更新时 null 被忽略导致移除专区商品假成功问题 - 通过 UpdateWrapper 显式设置 section_ids 字段避免 MyBatis-Plus 全局更新策略影响 - 补充后端下单接口白名单强校验，防止绕过前端受限专区限制 - 澄清买家用户体系为 sys_user，确认白名单弹窗使用 pageUsers 数据源正确 - 删除白名单弹窗 isStaff 限制，白名单覆盖所有 sys_user 用户 - 记录专区白名单功能设计与实现细节，明确前后端联动机制 - 提示“专区管理”菜单入口需后端菜单表动态下发，确保后台导航可见
4.0 KiB
4.0 KiB
2026-08-17 工作日志
专区商品「移除」假成功 bug 修复
- 现象：guilixu.websoft.top/special/zone 移除专区商品提示成功，刷新（重查库）后商品仍在。
- 根因：
ShopHomeSectionController.removeGoods用listByIds+updateBatchById改shop_goods.section_ids；单专区商品移除后 section_ids 变 null，但ShopGoods.sectionIds无更新策略注解，MP 全局默认NOT_NULL会忽略 null 值 → 不生成SET section_ids=NULL→ 库字段保持原值（假成功）。多专区商品（变非 null）正常，故仅单专区场景坏。 - 修复：
addGoods/removeGoods改用UpdateWrapper.set("section_ids", newVal).eq("goods_id", id)显式更新（newVal 可为 null），绕过字段策略。文件：guilixu-javaShopHomeSectionController.java。 - 部署：需重新编译部署 guilixu-java（线上 shop-api）后端生效；前端无需改动。添加用同样模式统一修复。
- 验证：部署后用单专区商品移除测试，刷新不应再出现。
- 注：本机环境无 maven，未本地编译；改动为标准 MP 用法（IService.update(Wrapper) / UpdateWrapper.set 允许 null）。
专区白名单功能诊断（功能当前不可用）
- 设计意图：专区设为"受限专区"(restricted=1) 后，该专区商品仅白名单用户可用余额购买；小程序结算页 checkout.tsx 已调
check-permission前端拦截。 - 致命错配：后台白名单弹窗
UserSelectModal.vue用pageUsers(@/api/system/user → sys_user 后台员工) 选用户；后端ShopHomeSectionController.checkPermission用getLoginUser().getUserId()（= shop_user 小程序买家 userId）。两套用户体系 id 不一致 → 白名单里加的任何人（后台员工）对真实买家都匹配不上 → 受限专区对买家永远拦截/强制余额，白名单形同虚设。 - 次要隐患：后端创建订单接口未做白名单强校验，仅前端拦截，可被绕过。
- 修复方向：① 白名单弹窗数据源从
pageUsers(sys_user) 改为pageShopUser(@/api/shop/shopUser → shop_user 买家)，使存的 user_id 与校验 userId 同体系；② 后端下单接口加白名单强校验防绕过。后台已有 pageShopUser 可用。
专区白名单：用户体系澄清 + 后端强校验（用户 2026-08-17 01:50 指令）
- 用户澄清：本项目的买家(小程序用户)就是
sys_user体系，pageShopUser实际不用/返回空。故白名单弹窗用pageUsers(sys_user) 是正确的，之前"用户体系错配"判断为误判。 - 白名单弹窗
UserSelectModal.vue现状（8-16 已改）：pageUsers({ keywords, ... })，不传 isStaff（搜索覆盖全部 sys_user）。源码无需再改。已 grep 确认 zone 目录下无残留 isStaff/pageShopUser。 - 后端补「受限专区白名单强校验」：
OrderBusinessService.java新增- import：
ShopHomeSectionService、ShopHomeSectionUserService、QueryWrapper、java.util.Set/LinkedHashSet； @Resource注入homeSectionService、homeSectionUserService；createOrder在validateDeliveryRegionIfNeeded之后调用validateSectionPermissionIfNeeded(request, shopOrder, loginUser)；- 新方法逻辑：遍历
request.goodsItems→ 取ShopGoods.sectionIds→ 找 restricted=1 的专区 → 校验loginUser.getUserId()是否在shop_home_section_user（count>0），否则抛BusinessException("该商品属于受限专区，仅限指定白名单用户购买")。
- import：
- 作用：前端
check-permission的后端兜底，防止直接调/shop/shop-order下单绕过白名单。 - 部署：需重新编译部署 guilixu-java（shop-api）。前端无需改动。
- 注：本机无 maven，未本地编译；改动为标准 MP 用法（IService.count(QueryWrapper) / getById）。
- 待确认：用户 "2.帮我补" 指令只写了前半句，已按上文补后端强校验；若其本意是"补菜单记录"(专区管理入口，动态路由待插入)，需另出 INSERT SQL（菜单表结构待确认）。