保安服务网

推送通知整改说明

推送系统整改报告（阶段进展）

一、背景与目标

资讯（News）、生活信息（Life）等内容模块当前仅部分支持短信推送，且逻辑分散在多个控制器函数中，存在重复、难以维护的问题。
微信、站内信、邮箱推送各自为政，缺乏统一的调用规范与发送统计；会员端、商户端、WAP 端体验不一致。
参考短信验证码模块化改造成果，需要在不打破现有短信、微信等模块边界的前提下，实现资讯/生活类推送的统一封装和多渠道扩展。

二、业务约束与提示

模块化边界：短信、微信等基础发送模块需保持解耦。整改时应在上层新增推送服务，调用底层现有接口（SmsModel、WeixinmsgModel、Email 等），避免直接改动底层实现。
接收对象颗粒度：同一推送可能面向商户、会员、公司员工或自定义人群。现有数据结构中可通过关注关系（shop_favorites）、订阅表（life_subscribe）等区分对象类型，推送服务需支持传入不同的接收列表。
计费约束：短信、微信推送均受购买条数/余额限制。整改方案需在发送前检查推送方（商家/个人）的可用额度，失败时给予明确提示并避免计入成功统计。
自动订阅（未来扩展）：当商家或个人订阅了资讯/生活类信息，系统应自动推送最新内容。该能力本阶段仅完成架构预留，不立即上线，实现手动推送与通道统一后再扩展。

三、现状梳理

模块	入口	当前推送能力	问题
商户资讯 `Merchant/News`	`http://localhost/merchant/news/index.html`	提供短信/微信/站内信按钮；逻辑分散，重复查询；无邮箱推送；日志依赖调试文件	推送代码冗长，缺乏统一错误处理与统计
会员资讯 `Members/News`	`http://localhost/members/news/index.html`	仅具备列表管理，无推送入口	不能满足手动推送需求
WAP 资讯 `User/News`	`http://localhost/user/news/index.html`	仅有编辑/删除	无推送入口
WAP 生活信息 `User/Life`	`http://localhost/user/life/index.html`	支持置顶/加急/刷新/删除	无推送功能；订阅模型未用到
订阅/关注	`shop_favorites`、`life_subscribe`	记录短信/微信/站内关注；部分接口（如 `LifeSubscribe::pushSubscribe`）已对接微信	缺少统一抽象封装；站内信/邮箱未整合

四、整改总体方案（执行中）

推送服务层 PushService 已落地

- 提供 pushArticle() / pushLife() 方法，统一处理接收者筛选、渠道分发、结果统计；

- 兼容 Article 与 Shopnews 双表结构，自动记录 is_tuisong_* 状态；

- 渠道参数现已支持 sms / weixin / msg / email，统计返回成功/失败/跳过数量。

渠道发送逻辑

- 短信：复用 SmsModel::sms_zcxmgg，已修复 $shop_id 未定义问题；

- 微信：封装 Wxmesg::tuisongweixin / Wxmesg::subscribe 调用，匹配资讯与生活模板；

- 站内信：统一调用 Msg 写入接口，标题/摘要/详情链接来自推送内容；

- 邮箱：统一调用 Email::sendMail('email_tuisongemail', …)。

- 生活信息模板增强：短信优先尝试 sms_life_push 模板（含分类、价格、链接），邮箱内容附带分类、时间与摘要，提升可读性。

调用及额度校验（已上线）

- PushService 已在短信、微信渠道调用前校验商家套餐余额，短信不足直接阻断推送；

- 阿里云短信通道补齐扣减逻辑（SmsModel::DySms）；微信渠道如存在独立套餐则按成功条数扣减。

控制器与界面改造（已完成首轮）

- Merchant/NewsAction、Members/NewsAction 现已改造为调用 PushService，并补充邮箱推送入口；

- User/NewsAction、User/LifeAction 新增 push 接口，返回统一 JSON；

- PC 会员、商户、WAP 资讯/生活前端按钮已连通 AJAX 逻辑；

- 反馈文案统一：“正在发送”“推送成功/失败”。

日志与监控（已落地基础能力）

- PushService 统一将每次推送统计落地到 Runtime/Logs/push/push_YYYYMMDD.log；

- 日志记录上下文、渠道、成功/失败/跳过数量，便于后续接入后台查看；

- 后续可在后台新增读取接口或归档任务。

未来扩展预留

- 推送服务支持订阅触发模式：新增事件/队列，在用户订阅内容发布时自动调用 PushService；

- 预留对自定义人群、批量调度（定时推送）的接口。

五、涉及数据结构与依赖

by_article：需确认 is_tuisong_sms / is_tuisong_weixin / is_tuisong_msg 等字段存在；若无邮箱字段，可新增 is_tuisong_email 等。
by_shop_favorites：提供 is_sms / is_weixin / is_msg 等关注开关，既是接收人来源也是开关控制。
by_life_subscribe：记录生活信息订阅者与分类，推送时按分类过滤。
SmsModel、WeixinmsgModel、Email、Msg：分别负责底层发送；整改中仅调用。
计费/套餐：需核实短信、微信的计费入口（如 Smsbao、Dayu_sms、Weixintmpl），推送前读取余额或剩余条数。

六、风险与测试重点

多渠道并发：同一批订阅者可能同时收到多个渠道消息，需防止重复/错发。
额度扣减准确性：失败重试时避免重复扣费；引入发送日志可回溯。
前端交互：确认所有新增按钮在 PC/WAP 环境下显示正常，弹窗/提示无乱码。
回归测试建议：

- 商户后台：资讯审核后测试四种推送；

- 会员后台/前台：资讯列表新增推送；

- 生活信息：推送给订阅用户，并检查 LifeSubscribe 自动触发预留；

- 极端场景：订阅列表为空、用户无手机号、短信额度不足、微信模板缺失等。

七、实施步骤（最新进展标记 ✓）

✓ 实现 PushService 核心逻辑并兼容资讯/生活双入口；
✓ 改造商户资讯推送流程；
✓ 改造会员/WAP 资讯、生活信息推送接口与前端；
✓ 额度校验与推送日志落地；
◻ 覆盖测试与回归报告；
◻ 自动订阅触发预研。

八、当前输出物

Banyan/Lib/Service/PushService.class.php：统一推送服务；
Merchant/NewsAction / Members/NewsAction / User/NewsAction / User/LifeAction 改造；
PC/WAP 前端推送按钮与 AJAX 交互；
`

帮助中心