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)
从真实页面的测量与复现出发，优化请求竞态、状态同步、列表渲染、包体积和表单反馈，并验证接口幂等边界、代码规范及关键业务交互。适用于保留现有技术栈的 Vue 存量工程。
## 任务目标 请完成选定 Vue 页面或模块的性能、状态一致性与交付质量优化，先测量问题，再落地代码并验证。指标未给出时先记录基线并提出与场景相符的目标，不虚构响应时间、提升比例或用户规模。 在现有授权范围内完成实际改动和验证；缺少外部条件时先完成可独立实现的部分，不能只停留在计划。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 优化对象或现象：优先定位对话中提到的慢操作或状态错乱；未描述现象时，从当前页面的首屏、筛选、分页和编辑切换建立基线，先处理可复现的状态错误和重复请求。 工程或复现资料：使用已确认工程的路由、组件、请求封装、store、测试数据和现有性能记录；可运行时自行采集网络、渲染和构建产物证据。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 核实 Vue 2/3、JS/TS、请求库、UI 库、路由缓存及现有 watcher 清理方式，不要求用户手填版本。 - 沿筛选、翻页和切换记录检查状态写入、请求取消、旧响应及 finally 的生效条件。 - 记录代表性操作的数据规模、模式、缓存、设备和网络条件，分开测量接口等待、重复请求、计算与组件更新。 - 检查模板循环、字典查找、资源导入、路由拆包和真实产物，确定优化影响范围。 ### 可采用的默认处理 - 未给性能指标时先采集可复查基线，以消除已证实浪费且业务不回归为目标，不承诺任意提速比例。 - 优先局部状态、纯 computed 与必要副作用清理；未证实瓶颈前不引入虚拟列表、全局缓存或 memo。 - 保留当前分页、选择及字典语义，写请求超时显示结果待确认，不把取消请求当作撤销业务。 ### 必须有依据的事项 - 优化涉及跨页选中、缓存失效或租户切换，而代码与接口无法确定需要保留的业务状态。 - 写操作结果未知且接口没有查单、幂等或补偿依据，不能自行重试并宣称提交成功。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 无法运行页面时交付按代码证据排序的瓶颈候选、状态写入图和最小修正，另给同条件测量步骤。 - 没有代码时给出筛选竞态、重复提交、页面恢复的复现与验收用例，不填造耗时或包体数据。 ## 执行要求 关注用户操作结果和可复查证据，不为了使用优化技巧改动系统架构。 ### 读取工程并建立可比基线 确认目标目录、分支和 dirty 改动，保留原有内容，只改选定范围。核实 Vue 2/3、JS/TS、API 风格、构建框架、UI 库、store、路由、请求库和锁文件，保留选型，不默认升级或迁移。复现首屏、筛选、翻页、弹窗、切换记录等实际问题；记录数据规模、生产构建或开发模式、缓存状态、设备及网络。结合浏览器性能、网络、Vue DevTools 和构建分析，区分接口等待、重复请求、脚本计算、组件更新和资源加载；权限或数据错误优先于微小速度收益。 ### 定位结构与状态责任 页面编排流程，业务组件承接领域交互，通用组件负责稳定通用契约，composables/hooks 管理组合式逻辑和清理，API 层统一请求契约，store 管理必要共享状态，types 与 styles 各归其位；按问题整理现有模块，不建空目录。纯无副作用函数进入 util，领域规则集中在业务模块，真正共用的响应式能力才复用。不要把数据、权限、表单和所有展示塞进万能组件或 util，也不为性能把所有状态搬入全局。 ### 消除状态不同步 为查询条件、分页、选择项、表单和缓存分别确定唯一写入来源，派生值用 computed，props、事件载荷和 v-model 契约明确，不直接修改父级状态。检查路由返回、筛选重置、切换租户或记录、删除末页数据后的状态；分页和选择项的保留规则必须对应业务。编辑副本说明与源数据同步时机，避免双向 watch 相互回写。枚举和魔法值与服务端数据库码、权限及字典一致，已有字典继续复用，禁止复制另一套状态映射；失效缓存不得让旧权限或旧字典继续控制操作。未知或停用字典码保留原始值并作可识别提示，禁止映射为成功、首项或任意合法状态；编辑提交按真实接口契约处理，不为消除告警擅自改写原值。 ### 处理请求竞态和副作用 快速输入、连续翻页、切换弹窗记录会形成并发请求。按当前请求库取消可取消的旧请求，同时用序号或请求条件快照保护结果、错误和 finally，确保过期请求不能覆盖当前内容或解除新请求的 loading；不同业务请求分别维护状态。取消客户端请求不代表服务端业务已撤销，写操作超时不能直接自动重试。watch 只监听必要源，避免无边界 deep 和回写循环；清理失效请求、监听、定时器与订阅。Vue 3.5+ 的 onWatcherCleanup 必须同步注册，低版本使用其支持的清理机制和生命周期；离开、卸载及缓存页面停用时按实际行为处理。 ### 控制计算与渲染成本 v-for 采用稳定唯一的业务 key，排序和编辑列表不用索引、随机值或时间戳。将模板和循环中昂贵过滤、排序、格式化、字典查找移到有明确依赖的派生层；computed 保持纯计算，不夹带请求或状态修改。对重复查找按数据规模建立合适索引，注意索引随源数据更新。避免每项都发请求；优先真实可用的批量查询或服务端分页，没有接口时说明限制并控制并发，不伪造后端能力。检查 props 是否反复创建无意义新对象、组件是否无关更新；按证据减少渲染，不盲目 memo、深比较、shallow API 或缓存，防止失去必要更新。 ### 按场景优化列表与资源 根据实测 DOM 数量、交互延迟和数据规模选择分页或虚拟列表，核验行高、滚动定位、选择项、键盘操作与 UI 库能力，不用固定条数一刀切。测量实际生产包、关键路由资源和重复依赖，按既有构建能力优化导入、路由懒加载及重资源加载时机；确保首个操作不会因拆包失败失效。移除代码或依赖前核查自动导入、动态路由、按需组件与注册入口。缓存明确键、有效期、失效条件及身份边界，不用长期全局缓存掩盖接口问题。任何优化都要有前后相同场景的记录，不能以依赖宣传体积代替实际产物。 ### 完成可用的业务反馈 区分 loading、empty、error、成功及权限不足，失败不可显示成空数据，保留数据或清空数据按场景说明。正确区分 null、未提供、0、false 和空字符串。表单按输入、失焦与提交时机校验，错误就近展示并可纠正；服务端失败保留合理输入，弹窗关闭、重新打开不残留旧结果。提交时即时反馈并防重复点击，后端幂等键、唯一约束和事务仍由接口承担；没有后端能力时写明局限，不能把防抖当幂等。失败后给出真实可行的恢复路径，不吞错、不伪造成功。 ### 把优化纳入既有规范 保持政企中文界面的层级、对齐、间距、表格密度、主次操作和反馈一致，不添加非业务口号与技术说明。命名清楚，注释解释业务原因、接口限制和性能取舍，不逐行注释。使用兼容版本的 ESLint、eslint-plugin-vue，TS 工程配套 typescript-eslint，并保留 .vue 与脚本解析器分工；沿用 flat/legacy 模式和现有 ESLint 或 Prettier 格式方案。统一空格、缩进、换行、引号、分号、导入及文件区块顺序，对齐 .editorconfig；兼容配置只解决格式职责冲突，不降低质量门槛。零新增 lint 违规，不用 disable、扩大 ignore、any 或 ts-ignore 隐藏问题，不整仓格式化制造无关差异。 ## 交付与验收 ### 验证结果并完成交付 实际执行相关 lint、适用的 typecheck、生产 build 和关键交互验收；JS 工程无类型检查时说明不适用，工具或环境缺失则标记未执行。至少覆盖正常与空数据、未知与停用字典码、接口失败与恢复、快速筛选翻页、旧响应晚到、连续提交、切换记录、返回页面和权限变化；验证表单失焦、弹窗焦点、中文换行及新产生的控制台错误。只在隔离且获准的测试环境模拟网络故障，不影响真实业务。性能比较保持设备、数据、模式及缓存条件一致，多次记录波动，分别列包体积、请求量、渲染或交互指标；改善不能以业务回归为代价，未改善也如实报告。 输出：①问题、复现及基线；②已实现改动与关键路径，说明结构、状态和请求规则；③实际生效的检查与格式配置；④优化前后指标和测量条件；⑤验收项目、命令或操作、结果及未执行原因；⑥剩余限制和最小后续工作。保留历史失败与新增问题的区分，未跑不宣称通过，没有测量不宣称提速。完成已授权实现，不只提交建议，不生成无关 Markdown 文档。 ### 本条完成检查 - 记录问题、基线、实际修改和相同条件下的优化前后指标，未改善或未测量如实列明。 - 验收旧响应晚到、finally 竞态、快速分页、记录切换、权限变化及未知字典码，不以性能收益抵消业务错误。 - 执行相关 lint、适用类型检查、生产构建与关键交互，列出真实命令、结果和剩余限制。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方依据：Vue 性能：https://vuejs.org/guide/best-practices/performance.html、Vue 监听清理：https://vuejs.org/guide/essentials/watchers.html、阿里前端规约：https://github.com/alibaba/f2e-spec、Vue 插件配置：https://eslint.vuejs.org/user-guide/、Prettier 与 Linter：https://prettier.io/docs/integrating-with-linters。 收录核验（2026-09-08）：已核对公开资料和本次项目要求的覆盖范围；尚未使用真实项目执行本模板或进行模型效果评测。具体改动、性能和回归结果须在目标工程中验证。
