2025年10月24日
1、xinle_push_app_hook集成了日志记录和计数器功能，用于全面监控消息推送的成功与失败。当用户成功推送消息后，系统会通过xinle_redis_count记录成功次数（计数器标识为app_push），该计数器支持按年、月、日等指定时间范围查询，从而统计APP消息的发送总量，便于后续分析与追踪。如果消息推送失败，系统会通过xinle_log_error_warn记录错误日志，详细描述推送失败的相关信息。日志的格式如下：[错误时间: " . date("Y-m-d H:i:s") . "] - [收信用户: {$userId}] - [推送编号: {$result_id}] - [错误信息: {$errorMsg}]。这种设计既能帮助开发者快速定位问题，又能实现推送数据的高效统计和管理，为后续优化提供了可靠的支持。
2、xinle_push_app_hook 函数执行流程 整体遵循 “先检查→再执行→后收尾” 逻辑，核心是确保推送有效且可追溯，异常情况全拦截。 参数检查：先看必填参数（用户 ID、通知类型 / 标题 / 内容）是否齐、格式对，不对直接返回错误。 用户推送码验证：获取用户的 APP 推送码，没有或无效就终止，返回 “未绑定推送码” 错误。 存数据库待推记录：把推送信息（用户 ID、内容、状态 “待推送” 等）写入数据库，存失败就报错。 调 API 推送：拿配置好的 API 地址、APP 密钥等，发推送请求；请求失败或返回错误，就更新数据库为 “推送失败”，记日志，返回错误。 推送成功处理：更新数据库为 “推送成功”，累加推送统计，返回成功结果。 异常兜底：遇到没预料到的错，记详细日志，返回 “系统异常” 的友好提示。
3、当前项目已集成以下三类消息推送功能，分别为公众号模板消息推送函数（xinle_gzh_push($gzh)）、手机短信发送模板推送函数（xinle_sms_push($sms)）以及APP消息推送发送函数（xinle_app_push($app)）。这三个消息推送功能均支持异步处理，以提升推送效率，并结合redis缓存技术优化数据存储与访问性能。此外，系统还集成了日志追踪功能，用于记录推送过程中的详细信息，方便后续问题排查。同时，每次推送操作会记录至相关数据表中，确保推送数据的完整性与可追溯性。这些推送功能既支持系统自动执行，也支持手动触发执行，为项目的消息推送功能提供了高度的灵活性和可靠性，有效提升了用户消息通知的体验和运维效率。
4、xinle_email_push方法已进行重构设计，优化了参数传递方式，由原来的变量传参调整为数组结构传参，以提高扩展性和可读性。当前支持的数组字段包括以下内容：email（邮箱账户，与用户UID为二选一必填项）、user_id（用户UID，与邮箱账户二选一必填项）、title（邮件标题，必填项）、content（邮件内容，必填项）、type（邮件类型，默认为default）、以及attachment（附件路径，默认为空）。通过这种设计，方法可以更加灵活地处理邮件发送请求，同时支持多种业务场景。执行结果以数组形式返回，其中包含code（状态码）和msg（提示信息），用于标识邮件发送的成功与否及相关反馈内容。这种设计不仅提高了方法的可维护性，还增强了邮件发送功能的适配性和稳定性。
5、重构后xinle_email_push整个执行流程如下：参数处理阶段从输入数组$email_push中提取所有必要参数（邮箱、用户 ID、标题等），并进行类型校验和过滤（如字符串去空），同时设置默认值（如type默认为default，asyn默认为false）。 基础验证阶段 校验收件人信息：邮箱和用户 ID 不能同时为空（至少需要一个定位收件人）。 校验核心内容：标题和内容不能为空（二者为邮件必需项）。 收件人信息转换阶段 若仅提供用户 ID，则通过xinle_is_user_email()获取其绑定的邮箱；若用户未绑定邮箱，直接返回错误。 若仅提供邮箱，则通过xinle_is_uid_by_email()获取对应的用户 ID（用于数据库记录）。 格式与频率校验阶段 校验邮箱格式是否有效（通过xinle_is_email()）。 限制发送频率：通过xinle_lock()实现 “5 秒内不允许向同一邮箱发送相同标题的邮件”，防止重复发送。 数据库记录阶段准备邮件数据（包含收件人信息、标题、内容、时间等），若有有效附件则一并记录，然后写入数据库并获取记录 ID。若写入失败，返回错误。 发送方式处理阶段 若为异步发送（asyn=true）：直接返回 “加入队列” 的成功结果，不执行实际发送。 若为同步发送（asyn=false）：初始化 PHPMailer，配置 SMTP 服务器参数，准备邮件内容（通过模板生成 HTML），执行发送操作。 发送结果处理阶段 发送成功：更新数据库记录状态为 “success”，记录统计信息，返回成功结果。 发送失败：记录错误日志，更新数据库状态为 “fail” 并保存错误信息，返回失败结果。
6、新增方法：xinle_notify_hook_service，这是一个统一的消息发送接口，用于服务号消息通知的钩子服务函数。该方法需要传递以下三个变量： $user_id：用户ID，标识具体的接收用户。 $type：通知类型，用于区分不同的消息类型。 $template：通知模板数组，包含消息内容的具体模板。 当 $template 为空时，函数会直接返回错误，提示“服务号消息发送失败：传递template空数组”。
7、新增方法：xinle_is_push_service，该方法用于检查是否允许发送服务号消息，主要依据用户的状态、推送配置和全局设置来判断。方法需要传递两个参数： $user_id：用户ID，用于识别具体用户。 $type：推送类型，用于判断该类型的消息是否允许发送。 函数将返回一个包含结果代码和消息的数组，具体逻辑如下： 如果允许发送站内信，结果代码为 0，消息为“允许发送APP通知”，同时返回的数组中还会包含服务ID和标题（前提是该类型的服务已配置）。 如果不允许发送站内信，结果代码为 1，消息将详细说明失败原因。 如果推送配置不存在、推送功能已被全局禁用，或者APP已被禁用，函数会返回一个包含错误代码和消息的数组，提示具体的错误原因。
8、后台新增功能模块：服务号消息模板（xinle_public_account）。该模块旨在实现公众号消息助理的管理功能，允许根据业务需求添加对应的消息服务号。不同的服务号可以独立负责不同类型的消息推送，以满足多样化的消息通知需求，同时支持灵活扩展。功能设计如下：模块名称：服务号消息模板（xinle_public_account）。主要功能：服务号管理：支持添加、编辑、删除服务号，定义每个服务号的职责范围。消息模板配置：每个服务号可以绑定不同的消息模板，用于定义推送的内容样式，例如标题、正文、消息链接等。消息类型分组：通过服务号对消息类型进行分组管理，使推送逻辑更加清晰。灵活扩展：支持动态添加新的服务号和消息模板，满足业务扩展需求。应用场景：交易助手：专门负责处理与交易相关的订单信息推送，例如订单状态更新、支付成功通知、退款进度等。余额助手：用于处理账户余额变动的通知，如充值成功提醒、提现到账提示、余额不足警告等。系统助理：管理与账户安全或系统相关的消息推送，例如密码修改通知、登录异常提醒、系统维护通知等。功能实现：后台提供一个界面用于创建和管理服务号。管理员可以为每个服务号设置名称、描述、绑定的消息类型以及对应的消息模板。服务号与消息模板之间可以一对一或一对多绑定，确保不同服务号能够灵活处理不同的消息内容。系统支持动态扩展，管理员可以根据业务需求随时新增服务号和对应的消息模板。
9、xinle_public_account 配置字段说明：该配置字段主要用于定义服务号的基本信息和功能属性，确保服务号的行为符合预期，同时为前后端联动提供必要的约束条件和接口支持。具体字段及说明如下： name：服务号的名称及使用场景介绍。该字段用于简要说明服务号的功能定位，例如“交易助手：用于处理交易订单相关通知”或“余额助手：负责账户余额变动提醒”。管理员在设置时需确保描述清晰，方便后续管理与用户识别。 key：服务号的唯一标识符。该字段在服务号创建时需设定，并且一旦确定后绝不可修改。key 是服务号的核心标识，前后端通过该字段进行数据关联和逻辑处理，因此必须确保唯一性和不可变性。任何修改都需经过前后端的协同调整，避免引发数据异常。 user_id：服务号绑定的虚拟用户 ID。系统会为每个服务号自动生成一个虚拟用户 ID，用于模拟消息的发送者身份。该字段一旦设定后同样不可更改，修改会导致历史消息记录及关联逻辑出现问题。前后端需共同保证该字段的唯一性和稳定性。 服务号介绍：用户在打开服务号时可见的内容，用于展示服务号的基本信息和功能说明。例如，“本服务号负责通知您的订单状态更新、余额变动等信息，请关注相关提醒”。该字段内容需清晰明了，方便用户快速理解服务号的用途。 pop（站内弹窗通知）：用于控制站内弹窗消息的开关状态。开启时，服务号可向用户推送站内弹窗通知；关闭后，即使用户在线，系统也不会再发送弹窗消息。该字段的设计旨在平衡用户体验与消息推送的干扰程度，适用于不需要频繁提醒的服务号。 msg（私信功能）：用于控制用户是否可以通过服务号发送私信。开启时，用户可通过服务号与后台进行私信交互；关闭后，用户无法发送消息，仅能接收服务号的通知。该字段适用于消息单向通知的场景，例如系统公告、账户变动提醒等。 api（消息转发接口）：用于配置服务号的消息转发功能。开启后，用户发送的消息将按照标准格式转发到指定的接口地址，便于后端系统处理用户请求。接口的具体使用规则需参照相关文档，确保消息的转发逻辑正确无误。
10、后端新增了 is 语法（xinle_is_public_account($key)），用于检测某个 key 或指定的 user_id 是否为服务号消息。当检测结果为服务号消息时，系统会返回该服务号的具体配置信息；若检测结果不是服务号消息，则返回 false。服务号是平台的虚拟账户，主要用于系统消息的下发与处理。在消息接收与处理的过程中，系统需要对消息的类型和来源进行判断，若识别为服务号消息，则需进行单独的处理，以确保服务号消息的处理逻辑与其他消息区分开来，从而实现更精准的消息分发与响应。
11、xinle_is_push_service完成封装处理，整个执行流程如下：初始化结果数组 创建一个空的 $result 数组，用于存储函数的返回结果。 获取推送配置 通过调用 xinle_is_config 函数，根据通知类型 $type 获取对应的推送配置 $push。 检查推送配置是否存在 如果未找到与通知类型匹配的推送配置，直接返回错误：通知场景未配置。 检查推送是否全局禁用 如果推送配置中的 open 值为空或为 false，表示当前通知场景已全局禁用，返回错误。 检查服务号通知是否启用 如果推送配置中的 service_open 值为空或为 false，表示当前通知场景禁用了服务号通知，返回错误。 检查服务号参数是否存在 如果推送配置中的 service_id 值为空，表示服务号参数未正确配置，返回错误。 获取服务号配置信息 调用 xinle_is_public_account 函数，使用 service_id 获取服务号的配置信息 $public_account。 检查服务号是否存在 如果 $public_account 为空，说明服务号不存在，返回错误，包含服务号的 service_id 信息。 返回成功结果 如果所有检查通过，则返回允许发送服务号通知的结果，包含： 状态码 code 为 0。 成功消息。 服务号标题 service_title。 服务号标识 source。 服务号的用户ID user_id。

2025年10月23日
1、新增了一个 Redis 计数器 gzh_push，用于记录公众号模板消息发送成功的次数。该计数器通过 xinle_redis_count 方法完成计数统计的处理，能够支持按时间区域进行查询，比如查询昨天、本周、上月的公众号消息推送成功次数。计数器的更新仅在接口明确返回推送成功时才会触发，确保统计数据的准确性。
2、在通过 xinle_gzh_push 发送公众号模板消息的过程中，如果 API 接口发生异常或者推送失败，系统会触发日志记录操作，以便后续分析问题原因和排查故障。日志的标识为 gzh_push，通过 xinle_log_error_warn 方法完成日志的写入处理。日志的记录格式规范如下：模版ID（temp_id）：标识本次发送的模板消息的唯一 ID，便于确定具体的消息模板。 返回码（result['code']）：记录接口返回的状态码，如果状态码不存在，则默认为 0。 失败详情（res['errmsg']）：记录 API 返回的失败描述信息，如果失败原因未知，则默认为 未知错误。 错误码（res['code']）：记录 API 返回的具体错误码，用于进一步定位问题原因。 接收用户（user_id）：记录本次消息的接收用户 ID，便于追踪特定用户的推送问题。
3、在 xinle_gzh_push 数据表中新增了一个 error 字段，用于存储推送失败时的详细错误信息。该字段采用 TEXT 类型，能够支持存储较长的文本内容，以满足复杂错误场景的记录需求，尤其是在微信接口返回较为详细的错误描述时，可以完整记录相关信息，便于后续问题排查和分析。 字段设计说明： 字段名称： error：用于记录推送失败的详细错误信息。 字段类型： TEXT：选择 TEXT 类型，允许存储大段文本内容，能够适应微信接口返回的复杂错误信息，例如错误码、错误描述、调用栈等。 默认值： 设置默认值为 NULL（允许为空），这样可以节省存储空间。只有在推送失败时（status='fail'）才会填充该字段，成功或等待状态下该字段保持为空。 使用场景： 当推送状态为失败（status='fail'）时，将错误信息写入 error 字段，以便后续分析和追踪问题原因。 推送成功（status='success'）或处于等待状态（status='pending'）时，该字段为空，避免冗余数据存储。
4、为了避免因并发或系统异常导致重复发送公众号模板消息，加入了 Redis 上锁保护机制。这种机制通过对业务逻辑的加锁控制，确保同一个用户在一定时间内不会重复接收到相同的消息。具体实现过程如下：系统在执行业务之前，会对传递的数组变量进行处理，首先使用 serialize 函数将数组序列化为字符串格式，确保数组的结构和内容能够完整保存。随后，使用 md5 对序列化后的字符串进行加密处理，生成唯一的哈希值。这个哈希值作为锁的标识，确保不同用户或不同消息能够独立区分。
接着，系统通过 xinle_lock 执行取锁动作。锁的有效期设定为 180 秒，即在锁定期间（180 秒内），同一个用户无法收到重复的模板消息。这样可以有效避免因系统异常或并发操作导致的重复触发问题。具体来说，当系统试图发送消息时，会先检查 Redis 中是否存在对应的锁。如果锁存在，则表示该消息已在锁定时间内被发送过，此时系统将跳过消息发送逻辑，避免重复发送。如果锁不存在，则说明该消息可以正常发送，并在发送完成后立即设置锁，锁的有效期为 180 秒。
5、xinle_sms_push方法重构设计，之前是通过变量传参，每个参数都需要通过变量来传参，这维护和扩展非常麻烦，因此决定对其进行重构，所有的变量都通过数组方式进行传参，需要什么就通过数组进行处理。内部方法进行全部重构设计，一些user_id和phone的逻辑进行重构，不在合并为一个，而是数组进行选择传参。支持手机号直接处理，也支持用户发送发送短信。
6、整个xinle_sms_push函数的执行流程可分为以下 10 个核心步骤，按顺序梳理如下： 1. 参数初始校验与提取 首先校验传入的sms是否为非空数组，若不是则返回 “参数格式错误”。 从sms数组中提取参数并设置默认值： phone（手机号或用户 ID，默认为空）、type（短信类型，默认为default）、templId（模板 ID，默认为空）、variable_1~variable_3（模板变量，前 1 个必填）、user_id（用户 ID，默认为空）。 2. 必传参数校验 校验templId（模板 ID）是否为空，为空则返回 “模板 ID 不能为空”。 校验variable_1（主要模板变量）是否为空，为空则返回 “主要变量不能为空”。 3. 手机号获取逻辑处理 若未传递phone但提供了user_id，尝试通过get_user_meta从用户元数据中获取绑定的手机号。 若phone仍为空（未传递且无法通过user_id获取），返回 “手机号不能为空”。 4. 手机号格式初步校验 校验phone是否为数字（排除非数字字符串），若不是则返回 “传递非法字符串”。 5. 用户 ID 转手机号处理 若phone不是有效的手机号（通过xinle_is_phone判断）但为数字（可能是用户 ID），尝试通过xinle_is_user_phone函数查询该用户 ID 绑定的手机号，若查询到则更新phone为实际手机号。 6. 手机号最终校验 再次通过xinle_is_phone校验phone是否为有效手机号，若不是则返回 “手机号错误”。 7. 用户 ID 关联处理 若未传递user_id，通过xinle_is_uid_by_phone函数根据手机号反向查询用户 ID，确保user_id与phone关联。 最终校验：若user_id和phone均为空，返回 “主要参数为空”。 8. 频率限制检查 生成唯一键（phone + templId），通过xinle_lock函数检查 “5 秒内同一手机号 + 同一模板” 是否已发送过短信。 若触发限制（未获取到锁），返回 “超速限制”。 9. 数据库记录与模板变量处理 准备短信记录数据（包含手机号、模板 ID、变量、发送时间、状态等），插入到xinle_sms_push表，获取记录 ID。 处理模板变量：去除空格、HTML 特殊字符和换行符，整理为腾讯云 API 要求的参数格式。 10. 调用腾讯云 API 并处理结果 准备腾讯云短信 API 参数（appid、appkey、签名、时间戳等），构造符合 API 格式的请求数据（包含手机号、模板 ID、变量、签名等）。 调用 API 发送请求，解析返回结果： 若返回errmsg = OK（发送成功）：更新数据库记录状态为 “成功”，记录短信 ID，返回成功信息（包含记录 ID）。 若发送失败：记录错误日志（时间、模板 ID、手机号、错误信息），更新数据库状态为 “失败”，解除频率限制锁，返回错误信息。 整个流程从参数校验到 API 调用、结果处理形成闭环，确保了短信发送的合法性、安全性和可追溯性。
7、系统中原有短信发送的旧接口已全面迁移至新版本方法进行统一处理。目前已完成的适配内容包括以下几项：1、短信注册功能已通过登录接口实现，确保用户在注册时能够顺利接收短信验证码；2、短信登录功能已通过登录接口适配，优化了用户登录时的验证码发送流程；3、换绑手机号页面新增了针对新手机重新获取验证码的功能，提升了用户在换绑操作中的体验；4、换绑手机号页面支持获取新手机号验证码，保障了用户信息修改的安全性；5、换绑手机号页面新增验证旧号码的功能，进一步加强了用户账户安全；6、绑定手机号页面已完成获取验证码功能的迁移，确保绑定流程更加稳定；7、修改密码时的验证码获取功能已适配至新版本方法，优化了用户操作的便捷性与安全性。以上功能的迁移和适配，有效提升了短信服务的稳定性和统一性，同时为用户提供了更加流畅的交互体验。
8、新增APP消息的推送方法：xinle_app_push($app)，该方法通过传递包含相关参数的APP数组来实现消息推送功能。目前已集成的字段属性包括以下内容：1、user_id：用于指定接收消息的用户，此字段为必填项，仅支持单体推送，即每次只能向一个用户发送通知；2、type：表示推送通知的类型，用于区分消息类别；3、$title：推送通知的标题，显示在用户端的消息列表中；4、$content：推送通知的内容，作为消息的主体信息展示；5、$payload：透传消息内容，该字段为可选项，主要用于传递一些后台数据或特定指令，不直接显示给用户。该函数通过调用特定的API端点实现消息发送，并在执行过程中会检查目标用户是否已绑定APP推送码，确保推送通知能够正确到达用户终端。此方法的引入进一步完善了消息通知机制，为用户提供了更加便捷和高效的消息推送服务。
9、新增数据表：xinle_app_push：负责记录APP消息的推送记录。字段说明： id：自增主键，唯一标识每条推送记录 user_id：关联用户表的用户 ID，用于定位推送对象 cid：存储用户的推送标识（clientid），用于实际推送操作 time：记录推送发起时间，默认值为当前时间 type：推送类型分类（如系统通知、私信等） title：推送标题（对应代码中的$title） content：推送内容（对应代码中的$content） payload：存储透传数据，以 JSON 格式保存（对应代码中的$payload） state：推送状态，默认为wait（等待推送），可后续更新为success或fail
10、xinle_push_app_hook在执行APP消息推送前，会先将推送信息写入推送记录表，以便进行后续的追踪和管理。写入记录后，函数会调用内置的API接口，发起APP消息的推送请求。推送过程结束后，系统会根据返回结果对记录的状态进行更新：如果推送成功，则会将状态字段status标记为success，表示消息已成功发送；如果推送失败，则会将状态字段标记为fail，同时将具体的错误信息详细记录到error字段中，以便后续分析和处理。该流程确保了消息推送的全程可追溯性，同时为异常情况提供了有效的记录支持，有助于提升消息推送的可靠性和问题排查效率。
11、xinle_push_app_hook在发起API请求时，由于涉及外部请求，系统会通过try-catch机制捕获可能出现的各种异常，从而确保不会因为意外错误而导致整个执行流程发生崩溃。在请求过程中，系统会优先处理官方接口返回的错误信息，并对这些报错进行识别和解析。如果官方返回的错误信息无法被系统识别或解析，则会启用内置的方法捕获系统级报错，确保所有异常信息都能被记录和处理。最终，所有的错误信息会被统一整理为数组结构返回给后续的接收对象，以便接收方能够高效地进行错误处理和问题追踪。这种机制不仅提升了系统的稳定性和容错能力，还为外部接口交互提供了可靠的异常管理方案。

2025年10月22日
1、新增后端方法xinle_is_user_email，用于检测用户是否已绑定邮箱。该方法的主要功能是通过用户的唯一标识user_id，判断用户是否已完成邮箱绑定操作。如果检测到用户已绑定邮箱，则直接返回用户的邮箱地址；若未绑定，则返回false。为了增强方法的灵活性，当未显式传递user_id参数时，系统会通过xinle_is_login方法自动获取当前登录用户的uid，确保能够动态适配不同场景下的调用需求。
2、xinle_is_push_email的处理流程如下： 构建 Redis 键名： 根据用户 ID 和通知类型生成 Redis 键名，格式为：day:push_{user_id}|email_{type}。 该键用于记录当前用户当天发送指定类型邮件的次数，便于后续的发送限制校验。 获取已发送邮件数量： 调用 get_redis_meta($redis_key) 获取 Redis 中记录的邮件发送数量，存储为 email_limit。 将获取的结果强制转换为整数类型，确保后续逻辑判断时数据的准确性和一致性。 初始化结果数组： 创建一个空的 $result 数组，用于存储最终的返回数据，便于后续结构化输出。 获取推送配置： 调用 xinle_is_config('xinle_push_config', $type) 方法，根据 $type 参数获取当前通知场景的配置，并存储为 $push。 使用 $type 参数过滤出对应类型的推送配置。 检查推送配置是否存在： 如果 $push 为空，说明当前通知场景未配置相关推送规则，返回错误信息。 检查场景是否已全局禁用： 如果 $push['open'] 为空或为 false，说明该通知场景已被全局禁用，返回错误信息。 检查邮件功能是否禁用： 如果 $push['config']['email_open'] 为空或为 false，说明该通知场景禁用了邮件功能，返回错误信息。 获取用户电子邮件地址： 调用 xinle_is_user_email($user_id) 方法，根据用户 ID 获取其绑定的电子邮件地址，存储为 $email。 检查用户是否绑定电子邮件： 如果 $email 为空，说明用户未绑定邮箱，返回错误信息。 检查是否达到每日邮件发送上限： 如果 email_limit 的值大于或等于 $push['config']['email_limit']，说明用户当天该类型邮件的发送次数已达到上限，返回错误信息。 返回成功结果： 如果以上所有检查均通过，表示允许发送邮件。 返回包含以下内容的结果：用户的邮箱地址 $email 和邮件标题（从 $push 中获取）。
3、新增方法：xinle_notify_hook_gzh，该方法旨在统一消息发送接口，主要负责封装模板消息的业务逻辑。具体实现流程如下： 方法功能： 该方法负责处理微信公众平台模板消息的发送，通过解析消息场景和对应的后台配置，结合用户信息和模板结构，实现消息发送的统一管理。 方法参数： $user_id：用户 ID，用于标识消息发送的目标用户。 $type：消息类型，通过解析消息场景来获取对应的后台配置信息。 $template：模板的组件结构，包含完整的消息内容和格式定义。
4、新增方法：xinle_is_push_gzh，检查是否允许发送公众号模版消息。如果推送配置不存在，或者推送已被全局禁用，或者模版消息已被禁用，或者公众号模版ID为空，或者用户的公众号模版推送UID有问题，或者已达到每日模版消息发送上限，函数将返回一个包含错误代码和消息的数组。返回一个包含结果代码和消息的数组。如果允许发送模版消息，结果代码为0，消息为'允许发送模版消息'，并且返回的数组中还会包含模版消息ID和用户推送标识。如果不允许发送模版消息，结果代码为1，消息将包含失败的原因。
5、新增方法：xinle_is_push_gzh，该方法用于封装公众号消息推送的逻辑处理，确保在满足配置要求的情况下对用户进行模板消息的发送操作。具体的执行流程如下： 构建 Redis 键名： 根据用户 ID 和通知类型生成 Redis 键名，格式为：day:push_{user_id}|gzh_{type}。 该键用于记录当前用户在当天发送指定类型的公众号消息的次数，以便对消息发送频率进行限制。 获取已发送的公众号消息次数： 调用 get_redis_meta($redis_key) 从 Redis 中获取记录的公众号消息发送次数，赋值给变量 gzh_limit。 使用强制类型转换将 gzh_limit 转换为整数类型，确保在后续的逻辑处理中数字比较的正确性，避免因数据类型问题引发错误。 初始化结果数组： 创建一个空的 $result 数组，用于存储最终的返回结果。该数组将在整个方法执行完成后返回，包含处理的状态及相关信息。 获取推送配置： 调用 xinle_is_config('xinle_push_config', $type) 获取通知场景配置，将结果存储到 $push 中。 根据 $type 参数过滤出当前类型对应的推送配置，确保后续逻辑处理的针对性。 检查推送配置是否存在： 如果 $push 为空，说明当前通知场景未配置，返回错误信息，提示配置缺失。 检查场景是否已全局禁用： 如果 $push['open'] 为空或为 false，说明该通知场景已全局禁用，返回错误信息，提示该类型消息推送已关闭。 检查公众号模板消息功能是否禁用： 如果 $push['config']['gzh_open'] 为空或为 false，说明当前通知场景禁用了公众号模板消息功能，返回错误信息，提示模板消息不可用。 检查公众号模板消息 ID 是否存在： 如果 $push['config']['gzh_id'] 为空，说明模板消息 ID 未配置，返回错误信息，提示配置不完整。 获取用户的公众号 UID： 调用 get_user_meta($user_id, 'weixin_uid', true) 获取用户的公众号 UID（即 weixin_uid），用于标识用户在公众号中的唯一身份。 检查用户是否关联公众号 UID： 如果 weixin_uid 为空，说明用户未关联公众号 UID，返回错误信息，提示用户未完成公众号关联，无法进行消息推送。 检查是否达到每日模板消息发送上限： 如果 gzh_limit 的值超过 $push['config']['gzh_limit']，说明用户当天该类型模板消息的发送次数已达上限，返回错误信息，提示发送频率受限。 返回成功结果： 如果以上所有检查均通过，说明满足模板消息发送的条件，返回允许发送的结果。 返回结果中包含关键信息，如用户 ID、模板消息类型、模板 ID 等，为后续的消息发送操作提供支持。
6、新增方法：xinle_gzh_push，该方法主要负责项目中公众号模板消息的统一发送，旨在实现业务逻辑的一致性和接口的高扩展性。为了便于后续维护和功能扩展，该接口采用数组传参的方式进行调用。具体逻辑及参数说明如下： 接口功能说明： xinle_gzh_push 作为一个统一的模板消息发送接口，主要用于向用户推送公众号模板消息，支持用户 ID 和 openid 两种方式指定消息接收者，并通过动态参数实现消息内容的灵活配置。 必须传递的参数： user_id（接收消息的用户 ID，与 openid 二选一）： 指定接收消息的用户，通过用户 ID 关联用户信息。 如果未传递 user_id，则需传递 openid。 openid（接收消息的标识，与 user_id 二选一）： 用于直接指定接收消息的公众号用户标识，通常在用户未绑定 user_id 时使用。 如果未传递 openid，则需传递 user_id。 temp_id（消息模板 ID 标记）： 必须传递的模板消息 ID，用于标识需要发送的模板消息类型。 该 ID 通常与模板消息配置的类型一一对应。 first（内容标题描述，已被系统禁用）： 此参数已被禁用，传递内容不会生效。 keyword1（第一个模板菜单内容）： 模板消息的第一个关键字内容，支持动态传参，用于个性化消息内容的展示。 keyword2（第二个模板菜单内容）： 模板消息的第二个关键字内容，支持动态传参，用于补充信息。 keyword3（第三个模板菜单内容）： 模板消息的第三个关键字内容，支持动态传参，用于展示更多细节。 keyword4（第四个模板菜单内容）： 模板消息的第四个关键字内容，支持动态传参，进一步丰富消息内容。 keyword5（第五个模板菜单内容）： 模板消息的第五个关键字内容，支持动态传参，用于展示额外信息。 remark（底部详细描述，已被系统禁用）： 此参数已被禁用，传递内容不会生效。 link（点击菜单的跳转链接）： 用户点击模板消息后跳转的链接地址，可配置为具体的业务页面或外部链接，用于引导用户进一步操作。
7、xinle_gzh_push 方法在处理 openid 的逻辑上进行了严格的校验和补充机制，以确保消息推送的准确性与稳定性。具体处理流程如下： 逻辑处理说明： openid 的优先读取与补充机制： 系统会优先读取传递的 openid 值，作为消息推送的接收标识。 如果调用方未传递 openid，但提供了 user_id，系统会通过 get_user_meta 方法根据 user_id 获取用户的 weixin_uid（微信唯一标识），并将该值赋给 openid。 如果经过上述补充后，openid 依然为空，则终止消息推送处理，并返回错误信息。 temp_id 模板标识的校验： 推送前会检测是否传递了 temp_id 模板标识，用于确定需要发送的模板消息类型。 如果 temp_id 为空，则主动跳过消息推送处理，并返回相应的错误提示。 消息发送与结果返回： 消息推送操作完成后，方法将返回一个标准的数组结构，方便调用方进行后续处理。 返回数组中包含以下字段： code：表示操作状态，code=0 代表推送成功，code=1 代表推送失败。 msg：具体的错误或成功信息，用于描述操作结果。
8、新增数据表：xinle_gzh_push：每次公众号模版消息推送（单向推送,非集体推送）都会在这个表写入推送记录，该表可以查看到消息是否推送成功，如果失败则会记录具体失败的原因。字段结构如下：id：自增主键，唯一标识每条推送记录 user_id：整数类型，关联系统用户表的用户 ID openid：字符串类型，存储微信用户的 openid tempid：字符串类型，存储使用的模板消息编号 json：TEXT 类型，存储推送的消息内容（JSON 格式） time：DATETIME 类型，记录发送时间 status：字符串类型，默认值为 'wait'，记录推送状态。
9、xinle_gzh_push 数据表新增字段 type，用于记录模板消息的推送场景来源，旨在为后期的溯源操作提供更精准的依据。在实际应用中，type 字段的设置与消息推送的具体场景密切相关，以下是详细说明： 字段设计与使用逻辑： 字段功能： type 字段用于标识模板消息的推送场景来源，例如订单通知、活动提醒、系统公告等。 通过该字段的记录，后续可快速定位消息的来源场景，便于数据分析、问题排查或业务优化。 字段赋值逻辑： 用户可以在调用接口时选择性传递 type 参数，用于明确指定模板消息的具体推送场景。 如果用户未主动传递 type 参数，系统会自动将其标记为默认值 default，以表示该消息为统一发送场景或未明确指定来源。 与公众号模板消息的关联： 在实际推送模板消息时，type 的值可以与对应的公众号模板消息类型进行绑定，以便在推送时区分不同的业务场景。 通过这种绑定机制，可以更高效地实现模板消息的分类管理，满足多场景的需求。
10、修复 xinle_sms_push 方法在完成短信发送处理动作后，写入消息数据表记录时错误地将 user_id 标记为 0 的问题。此问题的根本原因在于内部调用了 xinle_is_uid_by_phone 方法，通过手机号获取 user_id 时，由于参数传递错误，导致未能正确获取用户 ID，从而将 user_id 错误地记录为 0。
11、xinle_gzh_push 数据表的处理逻辑如下：在发起公众号模板消息推送之前，系统会通过 xinle_insert_sql 方法将本次推送记录写入数据表 xinle_gzh_push，并将其状态标记为 wait（表示等待发送）。随后，通过调用 API 接口向用户发送模板消息。如果发送成功，则将记录的状态更新为 success，若发送失败，则将状态更新为 fail。在处理公众号消息发送请求时，系统采用 try-catch 机制捕获可能的异常，确保无论发送结果如何，均能返回可供后续方法追踪的结果，从而保证推送过程的完整性与可追溯性。

最低多少钱？最低多少钱？

测试看看最低多少钱？

内容测试出