Java 后端与 Vue 前端对接微信支付 API v3，按需覆盖 JSAPI、H5、Native，下单、调起、回调验签、查单关单、退款、幂等及业务履约，包含数据库注释、完整测试和中文联调步骤。
## 任务目标 请在现有 Java 后端与 Vue 前端工程中，完成微信支付 API v3 对接。直接实现从业务订单发起支付、前端调起、服务端确认、业务履约，到关闭未支付订单、申请与查询退款的完整流程，交付可运行代码、数据库变更、配置示例、测试和中文使用步骤。不要只给 SDK 调用片段、演示按钮或没有接入真实订单的支付 Demo。 在现有授权范围内完成实际改动和验证；缺少外部条件时先完成可独立实现的部分，不能只停留在计划。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 支付业务：从当前对话和现有订单页面、订单服务中识别需要接入的收款业务，沿该订单的创建、支付、履约和退款链路实施；支付入口按工程已有终端和已开通产品确定，不因留空实现全部场景。 工程与接入资料：从当前工作区识别关联的 Java 后端和 Vue 前端，读取依赖、订单模型、权限、配置项定义及已有测试；商户资料只确认受控配置的来源和完整性，不要求粘贴秘密。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 追踪订单金额计算、状态更新、库存或权益履约、退款资格，以及对应表结构和唯一约束。 - 读取构建文件、支付依赖、SDK 封装、通知入口、Vue 支付路由及浏览器或小程序入口证据。 - 核对商户模式、AppID 与商户关系、公钥或平台证书方案、固定回调地址和已有配置校验。 - 查找测试配置、模拟微信适配层、迁移工具及可在隔离环境执行的测试命令。 ### 可采用的默认处理 - 先完成工程接入和无真实资金操作的隔离测试；缺商户材料时保留受控配置入口和明确的不可用状态，不伪造收款结果。 - 复用现有订单、权限、UI、数据库和支付库边界，不默认更换技术栈，也不增加分账、转账或合单产品。 - 支付场景不明时先完成公共订单、金额、幂等和通知基础，场景适配保持未启用，不凭 Vue 或浏览器标识猜商户能力。 ### 必须有依据的事项 - 无法从业务资料确定应付金额、合法收款对象、订单权限、履约或退款资格时，不能自行制定会改变资金或权益的规则。 - 商户模式、应用绑定或已开通产品不明时不启用对应真实接口；真实支付与退款所需的测试订单和金额授权缺失时不执行资金操作。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有工程时交付订单与支付退款关系、接口契约、状态及额度不变量、配置项说明和隔离测试样例，明确尚未完成项目接入。 - 缺真实商户环境时完成可执行的本地编译、模拟 SDK 交互及签名通知测试，列出按场景剩余的真实联调条件。 ## 执行要求 ### 确认范围和接入前提 读取当前分支、未提交改动、订单模型、金额计算、登录、租户与组织权限、接口风格、异常处理、数据库迁移和前端路由。保留无关改动，复用现有订单、支付与退款能力，不因本次接入重建全部交易系统。 确认普通直连商户或服务商模式，核对商户号、应用 AppID 及其绑定关系、已开通的支付产品和交易场景。服务商模式使用对应官方接口与 sp/sub 身份字段，不能把普通商户代码简单替换商户号后使用。没有分账、转账、合单或订阅扣费需求时不引入这些产品。 Vue 是技术框架，不决定微信支付方式：微信内网页通常对应 JSAPI；手机外部浏览器按已开通能力接入 H5；PC 网页采用 Native 二维码。只有目标包含真正的小程序时才接入 wx.requestPayment，普通 Vue 网页不能直接把它当成浏览器 API。 先核对所选场景的授权域名、支付目录或域名配置、应用与商户关系及回调地址要求，不将不同用途的域名配置混为一项。未确认的场景列为待确认，只实现选定范围；不要为了“完整”强行开通和实现所有支付产品。 商户资料不足时继续完成接口边界、代码、数据结构和隔离测试，明确尚不能执行的真实联调步骤。不得伪造商户号、OpenID、预支付单、支付成功或退款记录。 ### 使用官方 API v3 SDK，明确证书和密钥职责 优先采用官方 Java SDK com.github.wechatpay-apiv3:wechatpay-java；检查官方发布记录与工程 Java、Spring、依赖版本兼容性，在构建文件中锁定具体版本。禁止填写 LATEST 或臆造不存在的方法；已有支付库需要先评估迁移影响，不重复接入两套签名和回调处理逻辑。 商户 API 私钥用于商户请求及所需调起参数的签名，商户 API 证书序列号用于标识商户签名身份；微信支付公钥及其 ID，或微信支付平台证书，用于验证微信响应与通知。API v3 密钥用于相关密文解密，不是商户私钥。AppSecret、API v2 密钥、API v3 密钥不能混用；网站 HTTPS 证书也不是商户 API 证书。 根据商户实际接入方式选择微信支付公钥模式或平台证书模式。核对当前 SDK 的 RSAPublicKeyConfig、RSAAutoCertificateConfig，以及 RSAPublicKeyNotificationConfig 等通知配置能力，选择匹配的实现；不能把 PUB_KEY_ID 当成商户证书序列号，也不能通过关闭验签解决未知密钥或证书问题。 沿用配置注入方式管理 merchantId、appId、商户证书序列号、私钥文件位置、API v3 密钥、公钥 ID 与文件位置或平台证书方案、支付与退款 notifyUrl、业务超时和查询参数。校验必填项和格式，输出可定位但不含秘密的配置错误。 私钥、API v3 密钥和 AppSecret 只在后端受控配置中使用，不进入 Vue 环境变量、浏览器存储、前端构建产物、数据库普通配置表、源码仓库或日志。示例文件只写占位符与来源说明，不要求用户把真实秘密贴到聊天中。 按 SDK 生命周期管理并复用配置与客户端，避免每次下单重新下载平台证书或初始化配置。处理密钥标识不匹配、证书有效性与响应验签失败，不接受“开发环境先永久跳过验签”的实现。 ### 先设计订单、支付单和退款单的关系 业务订单、支付尝试、微信交易和退款单分开建模。业务订单可以经历多次支付尝试，但每次尝试有明确身份与有效状态；同一笔成功支付不能重复履约。保留已有模型，确有缺口才新增表或字段。 本地支付单至少能表达：所属业务订单、用户与租户、支付渠道和场景、服务端选择的商户配置标识、商户订单号 out_trade_no、微信交易号 transaction_id、AppID、订单金额及币种、状态、有效期、支付成功时间、必要的预支付信息、幂等键、版本及创建更新时间。 退款单至少能表达：原支付单、业务退款单、商户退款单号 out_refund_no、微信退款单号 refund_id、申请金额与币种、原因、申请人和权限来源、退款状态、退款完成时间、幂等键及创建更新时间。字段按实际业务和官方响应确定，不凭示例增加无用字段。 为商户范围内的 out_trade_no、微信交易标识、out_refund_no 等建立合适的唯一约束，按当前数据库的空值和索引行为设计；业务幂等键结合订单、用户或租户及操作类型确定范围，防止跨用户复用。不能只依靠 Redis 锁或 synchronized 保证支付唯一性。 设计通知接收与处理记录，以及可靠业务事件或待处理任务。区分通知 ID、交易 ID、支付单 ID 与业务履约唯一键，重复通知去重不能只看通知 ID；同一交易的查单与回调必须进入同一套状态收敛逻辑。 新增任何表的所有字段都写详细中文注释，说明业务含义、金额单位、枚举值、空值与默认值，必要时标注时区、关联关系和敏感等级。按 MySQL、PostgreSQL 等实际数据库提供正确的建表和字段注释语法，不写跨数据库不能执行的通用 SQL。 业务状态集中使用枚举或字典，明确代码与数据库值的对应，不散落魔法值。分别定义支付未完成、结果未知、已支付和已关闭，以及退款申请、处理中、成功、失败或异常等状态；本地名称可沿用项目约定，微信状态按官方当前枚举做显式映射，不能把未知状态默认当成成功或失败。 ### 金额和下单必须由后端控制 前端提交业务订单标识、允许的场景及必要幂等标识，后端验证登录身份、订单归属、租户、订单是否可支付、库存或有效期，并从可信业务数据计算应付金额。不能使用浏览器传来的金额、折扣、商品描述、商户号或 AppID 直接下单。 微信接口的金额按所选接口要求使用整数最小货币单位，人民币通常为分。项目使用元时以 BigDecimal 进行精确转换并验证小数位和范围；不使用 float/double 计算金额，不通过静默四舍五入掩盖非法金额，防止整数溢出和非正数下单。 同一逻辑支付请求重复到达时返回已有有效支付尝试或当前支付状态。以业务订单为边界，通过条件更新、短事务锁或合适的唯一约束控制尝试创建与切换；不同幂等键、多个标签页和不同支付场景也不能同时创建多个可收款的有效尝试。创建中或结果未知的旧尝试仍需占用该位置；确需换号前先确认旧微信单不可继续支付，履约去重不能代替防重复收款。 二维码或预支付信息失效后，先按微信订单状态与官方规则处理旧尝试，再决定是否可重新下单；不能每次点击按钮都创建一个新订单。支付链接或预支付 ID 失效也不能直接当作微信订单已关闭。 对下单超时、连接中断、响应验签失败等结果未知情况，保存本地状态和原 out_trade_no，先查单或按该接口允许的相同参数重试，不能直接生成新商户订单号以规避错误。明确“微信已受理、本地未拿到响应”的恢复路径。 返回前端的调起参数按场景区分，使用明确 DTO，禁止混合返回所有字段让前端猜测。用户状态查询只返回该用户有权查看的金额、状态、有效期与必要动作，不透传整个微信响应或商户配置。 ### 实现完整的 Java 支付服务 按已有分层实现配置、Controller、业务 Service、微信支付适配层、DTO/VO、枚举和持久层。控制层做输入与协议处理，业务层处理状态和一致性，适配层封装 SDK 调用；不要用一个静态 util 承担全部支付业务。 按选定场景使用 SDK 中真实存在的服务，例如 JsapiService 或 JsapiServiceExtension、H5Service、NativePayService；需要调起签名参数时优先核对扩展服务能力。普通商户 SDK 的下单、查询与关闭方法以当前类型和官方示例为准，不混入 API v2 的 XML、MD5 签名或 unifiedorder 写法。 提供发起支付、查询支付状态、关闭符合条件的未支付单、申请退款、查询退款，以及支付和退款通知入口。路径、响应结构与项目现状一致；下面仅是职责示例，不是微信支付官方路径： - POST /api/payments：基于业务订单创建或复用支付尝试，返回场景及调起数据。 - GET /api/payments/{paymentNo}：核验访问权限后返回状态，必要时按节奏向微信查单并收敛本地状态。 - POST /api/payments/{paymentNo}/close：核验订单状态与操作权限，按查单、关单结果处理，不把本地取消当成微信已关单。 - POST /api/refunds：基于允许退款的业务记录和权限创建退款申请。 - GET /api/refunds/{refundNo}：返回经过权限过滤的退款状态。 - POST /api/payments/wechat/notify 与 /api/payments/wechat/refund-notify：按微信通知协议处理，不使用普通业务响应包装。 微信回调入口按需要精确放行普通登录鉴权，并以微信签名和业务核验确认来源；不能为回调放开整个 API 命名空间。业务下单、查询、关单和退款接口继续执行原有认证、权限和防越权规则。 支付和退款 notifyUrl 使用后端固定配置、微信能够访问的 HTTPS 接收地址，不接受前端指定任意回调地址。核对路径、POST 请求、代理转发和原始请求体保持完整，不能被登录跳转或统一响应包装截获；本机 localhost 地址不能直接接收公网微信通知。 使用 MyBatis 时，SQL 统一放 Mapper XML，不在 Java 注解、字符串或 Service 中编写 SQL；XML、Mapper 方法和实体字段对应清楚。使用其他持久层时沿用现有规范，不为这一项强行更换框架。 外部微信网络请求不要放在长时间持有数据库行锁的事务中。先保存本地操作意图，调用微信，再用短事务合并结果；失败和重启后根据持久化状态恢复。涉及一致性时说明事务边界，不以“加了 @Transactional”宣称外部支付与本地数据库能原子提交。 ### 正确处理 JSAPI、H5 与 Native 前端 Vue 沿用已有版本、UI 库、路由、请求封装和状态管理。支付页面展示订单摘要、可信金额、有效期和明确按钮；保持中文界面清楚、布局规整，不引入无关宣传、装饰图或额外 UI 框架。 JSAPI：先处理当前 AppID 下的支付用户身份。网页 OAuth 的 code 换取和 AppSecret 使用在后端完成；校验 state 并绑定登录用户和原支付流程，限制回跳目标。不能将其他 AppID 的 OpenID、UnionID 或前端随意填写的 OpenID 直接用于下单。 JSAPI 调起参数由后端根据本次预支付单生成，例如 appId、timeStamp、nonceStr、package、signType、paySign。timeStamp 为 Unix 秒数字符串，package 对应 prepay_id=实际值；前端不重算商户签名，不自行改写已签名字段。优先核对 JsapiServiceExtension.prepayWithRequestPayment 的参数生成能力。WeixinJSBridge 的调起方法与微信 JS-SDK 的 chooseWXPay 按选定方案分别映射字段，不能混用 timestamp 与 timeStamp；wx.config 的权限签名与支付 paySign 分别实现，不混成一套。 等待相应桥接或 SDK 就绪后再调起支付，处理不在微信内、能力不可用、用户取消、调起失败与回到页面。浏览器环境识别只用于选择交互路径，不能作为支付身份或权限依据。取消支付界面不等于订单已关闭，允许的再次支付依据后端订单状态判断。 H5：由后端使用 H5 下单并返回完整 h5_url，前端从已配置的商户页面按官方流程跳转，检查 Referer 没有被策略或中间跳转丢失。需要 redirect_url 时仅编码该参数值，保留原链接其余参数；发起域名和回跳域名按当前官方要求与商户配置匹配，不能认为任意子域名自动可用。回跳不携带可信支付成功结论。核对场景信息与用户终端地址来源，后端只信任受控代理链传递的客户端 IP，不能随意采用前端提交值、服务器自身 IP 或任意 X-Forwarded-For。 Native：后端返回 code_url，Vue 在本地使用适合工程的二维码库生成清晰二维码，不把支付链接交给无关第三方图片服务。显示订单金额和有效期，二维码过期、刷新、关闭弹窗和切换订单时清理旧状态；“刷新二维码”不能绕过后端重复支付控制。 嵌入小程序 web-view 的 Vue 页面单独识别，不能直接按公众号网页调 JSAPI 或 H5 支付；如该入口确有支付需求，按小程序实际开放能力设计原生页面承接，核对小程序 AppID、OpenID 与签名。识别到 MicroMessenger 不足以证明当前页面可直接使用某一种支付方式。 前端任何 success 回调、URL 参数、支付完成按钮和截图都不能更新后端为已支付。调起结束后向本系统查询状态；服务端用已验签的通知或可信微信查单结果确认支付。页面分别展示待支付、确认中、成功、失败或已关闭，等待通知期间不误报支付失败。 封装合适的支付流程与状态查询能力，处理组件卸载、路由切换、重复点击、多个窗口和再次进入。查询间隔、最长等待、退避与恢复条件配置化；前端停止轮询不代表业务放弃支付结果，后端仍要处理回调和必要补偿。 ### 支付回调先验真，再持久化和履约 读取通知原始请求体和 Wechatpay-Serial、Wechatpay-Signature、Wechatpay-Timestamp、Wechatpay-Nonce 等官方签名头，按实际 SDK 构造 RequestParam 并使用匹配的 NotificationParser 完成验签和解密。不能先重新序列化 JSON 再验签，不能只解密不验签，也不能假定签名头中的标识就是可信的商户身份。 密钥选择只能在后端受控配置中完成。未知标识、签名探测或验签失败不放行；按 SDK 与官方要求核对时间和防重放能力，不能把通知 create_time 简单当成首次支付时间或拒绝所有延迟通知。 验签解密后核验事件类型、支付结果、商户号、AppID、out_trade_no、transaction_id、金额、币种和本地订单关系。区分订单金额、用户实付及优惠字段，按官方含义比对，不能把优惠造成的实付差异误判为订单金额错误。通知中的附加字段只能用于受约束的关联，不能覆盖本地金额与身份。 重复通知、并发回调和主动查单共用一套幂等更新入口，采用数据库唯一约束、状态条件更新或必要的锁控制竞争。支付成功事实不能被随后到达的旧查询覆盖为未支付；退款也不能抹掉原支付成功事实。 先在短事务中提交支付事实与必要的业务状态或可重试履约任务，再应答成功。发货、开通权益、积分和外部调用等副作用通过可靠任务处理并有业务唯一键；不能先返回成功再只放进内存线程池，也不能在事务提交前发送不可回收的业务结果。 成功通知应答采用当前 API v3 要求的 HTTP 200 或 204，不返回 API v2 的 XML；优先使用明确的空响应实现。验签、解密或必要持久化失败时返回符合协议的失败响应，不用统一异常处理器把失败包装为 HTTP 200。合法重复通知在确认已可靠处理后可正常应答。 按官方时限尽快完成可靠接收，避免在回调里执行长耗时履约。商户、金额或订单关系不匹配的事件不得推动支付成功，保留受限的排查记录并进行可信查单；不要通过吞异常消除通知重试。 ### 查询、关单和履约的一致性 不能只依赖通知。对下单结果未知、长时间待支付、前端已返回但本地未确认、通知落库后履约失败等情况，使用持久化记录驱动有边界的查单和处理重试。复用现有调度或任务能力，记录次数、下次执行时间与处理结果，避免无限高频查询。 关单前后都处理支付竞争：本地超时或用户点取消不能证明微信未收款。对微信返回已支付、状态变化或关单结果未知的情况查单确认，不覆盖支付成功；订单是否释放库存或终止权益由业务规则决定。 实际支付发生在业务订单关闭边界时，保存支付事实并进入明确的异常业务处理，按已确认规则选择履约或退款，不能丢弃回调，也不能未经业务规则自动退款。 履约任务在重试、服务重启和多实例并发时只能产生一份有效业务结果。若外部系统不支持幂等，写清确认结果和人工核对路径，不宣称天然“恰好一次”。 需要核对账款时，按所选产品提供交易、退款记录与官方账单的业务核对入口，明确金额、优惠和时间口径。差异先记录和核实，不仅凭一行账单直接重复扣款、退款或强改订单；不把前端显示成功作为对账证据。 ### 退款覆盖受理、处理中和最终结果 退款必须验证操作角色、订单归属、支付成功事实、退款原因和业务资格。退款金额由已授权的业务退款记录确定；不允许前端任意指定他人交易号、商户号或超额金额直接退款。 明确支持全额退款、部分退款及多次退款的范围。每一笔逻辑退款使用稳定且唯一的 out_refund_no；重复点击和网络重试复用该退款单。申请结果未知时用原退款单号查单，不立即换号重新退款。 并发退款需在数据库中控制可退余额：已成功退款以及处理中、结果未知等尚未确定释放的申请都要按规则占用额度，不能只减去成功退款就允许并发超退。终态释放或调整额度必须有可信结果；金额始终使用精确整数单位。 使用当前官方 RefundService 及真实接口完成申请、按商户退款单号查询和退款通知处理。申请接口成功只代表受理或返回了当时状态，不能无条件把本地标为退款成功。依据响应、通知与后续查询识别 PROCESSING、SUCCESS、CLOSED、ABNORMAL 等官方状态，并明确异常后续动作。 退款通知使用独立业务入口或明确事件分发，但同样执行验签、解密、商户和原交易核验、退款单号、退款金额与原订单金额核验。通知与查询并发时复用幂等入口，退款成功不会被旧的处理中结果覆盖。 核对所用 SDK 通知模型的字段是否完整。例如 v0.2.17 的 RefundNotification 使用 getRefundStatus()，没有 getMchid()；需要核验官方退款通知中的 mchid 等字段时，可定义匹配官方报文的完整 DTO，并交给 NotificationParser 验签解密后解析，不能臆造 getter、拿支付 Transaction 代替退款通知，或为方便读取而绕过验签。 退款完成后的库存、权益、优惠券及业务状态按原业务规则处理。支付退款和业务补偿分别记录，部分退款不能简单关闭全部权益；需要异步处理时用可靠任务和唯一业务键。 Vue 展示申请中、退款处理中、已退款与需处理的异常等准确状态。到账时间依据实际渠道说明，不写死承诺；用户点击“退款”或接口返回受理不能立即显示“已到账”。 ### 日志、异常和代码规范 日志关联业务订单号、支付单号、商户订单号、退款单号、通知 ID 和必要的微信请求标识，便于定位一次交易。保留必要的错误码和上下文，避免直接输出完整 SDK 响应、通知明文、OpenID、令牌、签名和秘密配置；需要留存原始通知时明确访问控制和最小留存范围。 区分参数错误、商户权限错误、签名或解密错误、业务状态冲突、限流、网络失败与结果未知。只对允许的错误进行有边界重试，保持原逻辑操作身份；不得把所有异常统一视为“支付失败，可以重新创建订单”。 后端采用清楚的业务命名与中文注释，重点解释金额、状态、幂等、权限和事务边界；不堆重复代码、无用工具类和魔法常量。前端遵守当前 ESLint、类型和格式规则，空格、缩进与换行一致。 时间和有效期以服务端及可信支付结果为准，正确保存带时区的支付与退款时间；前端倒计时用于展示，不能决定财务状态。验证长整型 ID、金额、枚举与日期在 Java、JSON、Vue 和数据库之间没有精度或含义变化。 ### 必须完成的验证 先运行不产生真实资金操作的本地单元、集成与前端测试。模拟微信客户端与通知适配层，使用隔离的测试密钥和带真实签名验证过程的测试报文；不能让测试绕过验签，也不能让测试构造的通知进入真实商户订单。 测试至少覆盖： - 后端金额计算、精确单位转换、非法金额、订单归属与跨租户访问。 - 重复下单、不同幂等键或跨场景并发下单、已有成功支付、过期支付信息和同一业务订单多支付尝试；验证无法通过切换入口绕过有效尝试唯一性。 - 微信已受理但本地下单超时、接口验签失败、查单返回未支付或成功，以及未知状态处理。 - 通知正常、重复、并发、乱序、伪造签名、原始体被修改、解密失败、错误商户或 AppID、金额或订单不匹配。 - 回调与查单同时更新、数据库提交失败、持久化后任务未执行、重试履约与多实例重复消费。 - 本地关闭与支付成功并发、关单结果未知、业务已取消后确认收款。 - 全额及部分退款、重复退款、并发超退、申请超时、处理中、成功、失败或异常，以及退款通知与查询乱序。 - Vue 支付取消、调起失败、桥接未就绪、H5 返回、Native 二维码过期、重复点击、刷新恢复、离开页面和轮询超时。 列出实际执行命令、环境、样例、预期与实际结果。没有执行的测试写明原因，不能把代码编译、前端模拟成功或手工改数据库当作支付联调通过。 不要假定所有 API v3 产品都有可用沙箱。核对所选产品当前提供的测试能力，明确本地模拟与微信真实联调的区别。真实扣款和退款只用于用户已明确授权的测试商户、订单、金额与退款范围，不自动进行额外资金操作。 联调时核对真实支付单、通知接收、可信查单、本地订单与履约结果；退款另行核对最终状态。分场景记录实际浏览器、微信环境和验证范围，不能通过一个场景就宣称全部场景可用。 ## 交付与验收 ### 交付内容和完成标准 交付完整后端支付与退款代码、Vue 页面或业务组件、数据库迁移及全部字段注释、配置示例、必要依赖、接口请求响应示例、通知处理实现与测试。示例中的文件路径、接口路径和命令必须与实际工程一致，不能留下伪代码和等待用户自行补全的关键方法。 给出简洁的支付和退款时序，以及状态允许如何转换；说明通知、查单、关闭、退款与履约如何汇合，不只罗列类名。保留必要的接入条件清单，区分开发者已完成的代码和仍需商户平台配置的项目。 中文使用步骤写清：配置来自哪里及放到哪里、安装依赖、执行数据库变更、启动 Java 与 Vue、打开支付入口、运行本地测试，以及在授权范围内完成真实联调的方法。优先更新已有说明或在回复中给出，不随意新增总结类 Markdown 文档。 最终说明改动文件、启用场景、实际测试与联调结果、未验证事项，以及缺少商户配置造成的具体边界。只完成代码与模拟测试时就按这个范围交付，不宣称真实扣款、退款、到账或全链路已验证。 ### 本条完成检查 - 实际交付订单级有效支付尝试控制、服务端金额与权限校验、通知查单收敛、可靠履约和并发退款占额实现。 - 后端与 Vue 按选定场景贯通，新增表全部字段具详细中文注释，通知失败不能被包装为 HTTP 200。 - 记录编译、隔离测试和获授权的真实联调结果，明确尚未验证的场景，不以模拟成功宣称扣款或到账成功。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 本提示词结合微信支付 API v3 官方资料与工程一致性要求整理。商户接入条件、字段和 SDK 方法以实际锁定版本及当前官方文档为准；数据库结构、接口示例、幂等、事务和测试要求属于项目实现建议，不代表微信支付官方完整业务规范或认证。资料核验日期：2026-09-08；本提示词未代替具体商户的真实支付与退款联调。 [官方 Java SDK 与 v0.2.17 发布记录](https://github.com/wechatpay-apiv3/wechatpay-java/releases/tag/v0.2.17) [SDK 接入、调用与通知处理](https://github.com/wechatpay-apiv3/wechatpay-java/blob/v0.2.17/README.md) [证书与密钥职责](https://pay.wechatpay.cn/doc/v3/merchant/4024350132) [JSAPI 开发指引](https://pay.wechatpay.cn/doc/v3/merchant/4012791870) [JSAPI 调起支付签名](https://pay.wechatpay.cn/doc/v3/merchant/4012365339) [公众号网页授权](https://developers.weixin.qq.com/doc/service/guide/h5/auth.html) [微信 JS-SDK 接入与权限校验](https://developers.weixin.qq.com/doc/service/guide/h5/jssdk.html) [H5 调起与回跳](https://pay.wechatpay.cn/doc/v3/merchant/4012791835) [H5 支付场景与域名问题](https://pay.wechatpay.cn/doc/v3/merchant/4012791845) [Native 开发指引](https://pay.wechatpay.cn/doc/v3/merchant/4012791891) [小程序与 web-view 支付边界](https://pay.wechatpay.cn/doc/v3/merchant/4012791910) [支付成功通知](https://pay.wechatpay.cn/doc/v3/merchant/4012791861) [回调和查单配合](https://pay.wechatpay.cn/doc/v3/merchant/4012075249) [退款申请](https://pay.wechatpay.cn/doc/v3/merchant/4013071036) [查询单笔退款](https://pay.wechatpay.cn/doc/v3/merchant/4012791863) [退款结果通知](https://pay.wechatpay.cn/doc/v3/merchant/4013071196) [SDK 退款通知模型](https://github.com/wechatpay-apiv3/wechatpay-java/blob/v0.2.17/service/src/main/java/com/wechat/pay/java/service/refund/model/RefundNotification.java)
核对 Python 项目的 TCA 依赖漏洞扫描结果，区分版本命中、部署存在和业务可触达，形成最小兼容升级、回归验证及回退计划。
## 任务目标 任务：Python 依赖漏洞分诊与最小升级验证。基于所提供工程和业务证据完成检查，先读取可访问的工程与证据，可以推进的部分继续完成；仅对查证后仍影响结论的关键缺口提问；不要编造文件、日志、测量结果或已完成的操作。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 漏洞处置范围：以当前工程可找到的 TCA 报告为入口，优先核对部署中存在且报告风险较高的 Python 依赖；没有报告时先建立依赖和扫描覆盖清单。 工程或扫描资料：查找 requirements、项目锁文件、依赖管理配置、TCA 输出、CI 日志及已提供的部署清单，再按漏洞编号查官方公告。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 确定扫描提交、工具规则版本、识别文件和解析失败项，确认传递依赖是否被覆盖。 - 从锁文件与依赖树追踪直接、传递、开发、生产和可选依赖，并核对可取得的部署版本。 - 查阅具体公告的受影响与修复版本、触发条件及业务调用证据，不用风险分值代替适用性判断。 - 读取上层约束、实际调用点、现有回归测试和可回退制品记录。 ### 可采用的默认处理 - 默认只读分诊，先给最小兼容升级方案；只有明确要求修复时才改依赖和锁文件，不自动部署或降级。 - 缺少覆盖或调用证据时分别标为未覆盖、部署未知或可触达性未知，不填零漏洞或无风险。 - 优先兼容的最小修复版本，保留唯一依赖维护入口；责任人和处置期限未给出时列待指定。 ### 必须有依据的事项 - 无法确认真实部署版本或公告对应关系，不能确定该告警对生产的适用性及最终处置结论。 - 是否接受漏洞暂缓或回退后重新暴露漏洞属于业务风险决策，没有明确依据不得代为接受。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 只有锁文件时交付依赖引入路径、待核验公告清单和扫描覆盖缺口，不声称 TCA 已执行。 - 只有报告时完成告警归并、最小候选升级和实际使用点回归方案，把部署核验单列。 ## 执行要求 适用边界：检查已有依赖清单和 TCA 扫描结果的 Python 项目。先确认扫描工具实际识别的锁文件格式、传递依赖和运行时信息，不预设完整覆盖，也不把零告警等同于无漏洞。实际漏洞版本范围必须由所给官方公告核对，不能依赖记忆。 检查要求：从 TCA 报告提取组件、版本和漏洞详情，有修复信息时一并记录。报告中的低、中、高风险用于初步排序，仍需独立判断部署适用性并制定回归和回退方案。按项目实际版本解释规则，不机械沿用旧示例。 1. 固定本次扫描的提交、依赖文件、工具及规则版本，核对日志中的文件识别情况和失败项。分开列出已扫描、解析失败、未覆盖的依赖；材料不足时不得填成零漏洞，也不得补造扫描完成记录。 2. 将报告组件映射到实际安装环境，区分直接与传递依赖、开发与生产依赖、可选功能与必选组件。追踪是谁引入该版本，确认锁文件和部署环境是否一致；不能仅凭源码未直接导入就判定组件不存在。 3. 逐项核对官方公告的受影响版本、修复版本和触发条件，记录公告编号及核对日期。将版本命中、部署存在和业务可触达分别判断；缺少功能调用或配置证据时标为未知，风险等级仅作为排序输入。 4. 优先给出满足约束的最小兼容升级方案。传递依赖同时评估上层组件约束，说明依赖树和锁文件的变化；不要盲升最新版、直接删除锁文件或通过忽略告警作为修复。暂缓项写明负责人、期限和实际缓解措施。 5. 列出升级可能影响的导入接口、序列化、数据库驱动、网络调用等实际使用点，据此设计构建、单元及集成验证。记录升级前后组件版本、依赖冲突和目标漏洞复扫结果，扫描通过不能代替业务回归。 6. 用已验证的制品和对应依赖锁定状态设计回退。说明回退是否重新引入漏洞，以及触发和停止条件。区分待执行计划与已执行证据，对没有报告的测试和部署不得填写通过。 ## 交付与验收 输出：先给处置优先级；再给分诊表：组件、引入路径、实际版本、公告依据、触发条件、适用性、处置、责任人；附最小升级清单、回归用例和回退条件。 ### 本条完成检查 - 逐项列组件、引入路径、版本、公告、触发条件、适用性和处置优先级，并保留证据日期。 - 给出依赖树与锁文件的预期最小变化、业务回归及回退重新引入风险。 - 如已明确实施升级，分别报告安装冲突、漏洞复扫和业务回归实测，不用一种通过替代另一种。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 来源核验日期：2026-09-08。 - 腾讯 / 腾讯云代码分析 TCA《依赖漏洞扫描规则包》：https://tencent.github.io/CodeAnalysis/zh/guide/%E4%BB%A3%E7%A0%81%E6%A3%80%E6%9F%A5/%E8%A7%84%E5%88%99%E5%8C%85/dependency_vul.html 验证说明：已核对上述公开来源及具体规则或能力；本模板尚未通过模型对比实验或线上业务实测，不能以来源品牌、仓库热度或扫描分数代替验收。 来源许可说明：Tencent/CodeAnalysis主许可为MIT，LICENSE.txt单列第三方组件许可；该网页未单列文档许可。本条为中文原创整理，来源内容与本模板补充要求已在正文区分。
建立 Python API 的参数、边界、异常和数值对比测试矩阵，按项目支持范围选择运行环境，并保留真实测试证据。
## 任务目标 请为本次指定的 Python 接口补齐有意义的测试并完成验收。 在现有授权范围内完成实际改动和验证；缺少外部条件时先完成可独立实现的部分，不能只停留在计划。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 待补测试接口：优先选择对话中的接口、当前改动影响的公开函数或已失败用例；未给缺陷时按已有调用契约补齐正常、非法参数和关键边界测试。 接口或测试资料：读取目标模块、调用方、docstring、现有测试、依赖与运行矩阵，从实际实现和业务说明提取可观察行为。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 对照函数签名、实现分支和调用方确认默认值、空值、返回结构及异常约定。 - 检查已有测试遗漏、缺陷复现和独立参考结果，确定数值精度或金额计数规则。 - 读取最低 Python 版本、测试命令及设备条件，仅对实际 Paddle 接口识别动态图、静态图或梯度要求。 ### 可采用的默认处理 - 沿用现有测试框架和支持矩阵，以业务承诺为单位新增用例，不追求无意义的行数或组合数量。 - 没有性能或数值容差依据时不设置任意门槛；确定性计数、字段及异常先做精确断言。 - 随机和时间相关场景固定可控条件，测试用临时资源并隔离副作用，不污染生产数据。 ### 必须有依据的事项 - 业务或数学定义缺失，导致数值期望、合法范围或误差阈值没有可信依据；不能用被测实现反算期望来证明自己正确。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 缺设备时仍补齐可检查测试代码和输入矩阵，将设备相关用例注明待运行。 - 缺接口实现时按已知契约给出用例及断言设计，单列无法确定的数值期望，不伪造执行结果。 ## 执行要求 按接口实际支持范围确定测试要求。针对 Paddle API 时核对相应运行模式、硬件和精度；普通服务仅采用适用的参数、边界及断言原则，不强加飞桨特定的覆盖率、梯度或耗时门槛。 1. 先列出接口可观察行为、输入约束、输出结构和异常约定，指出当前测试实际覆盖的部分。每个新增测试必须验证一项业务承诺或曾经出现的缺陷，不为提高行数而复制同一条正常调用。 2. 为必选与可选参数建立测试矩阵，包含合法值、默认值、边界、无效类型、空值及有意义的组合。解释哪些组合受业务限制而不成立，不能用任意字符串堆出与真实接口无关的用例。 3. 对数值计算选取可信参考结果或独立实现，检查形状、数据类型和数值误差。误差阈值必须有算法、精度或项目规范依据，不能在测试失败后直接放宽到通过；普通业务计数和金额按其精度规则断言。 4. 根据支持范围选择解释器、依赖、运行模式及硬件。Paddle 特有的动态图、静态图或梯度检查只在相应接口适用时加入；未支持环境明确列为不适用，不能跳过后仍写全部平台通过。 5. 对异常输入断言错误类型和必要上下文，测试命名写出触发条件与预期结果。避免只断言“不为空”或“未抛错”，同时检查是否意外修改输入、遗留文件或污染全局状态，保证测试可独立复现。 6. 运行受影响测试并检查失败原因，修复后复跑对应范围。将偶发失败与稳定缺陷区分，记录随机源、环境和执行条件；只有出现新变更或未解决风险时才扩大回归，不用重复执行掩盖不稳定性。 ## 交付与验收 输出：测试矩阵、关键测试代码、已发现缺陷、实际执行结果及尚未覆盖的风险。缺少数学定义或业务契约时标出无法确定的期望值，先完成其他可判定测试；没有环境时只交付测试方案与代码，不声称验收通过。 ### 本条完成检查 - 测试矩阵覆盖真实合法值、默认值、非法类型、空值和关键组合，每条对应明确业务承诺。 - 断言输出、异常及输入不被意外修改；数值参考与容差依据独立且可追查。 - 交付测试代码、实际执行条件、通过失败与未覆盖项，不能将跳过设备计为该平台通过。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [百度飞桨《API 单测开发及验收规范》](https://www.paddlepaddle.org.cn/documentation/docs/zh/dev_guides/api_contributing_guides/api_accpetance_criteria_cn.html)
