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)
从真实负载和故障证据出发，完成批量访问、幂等、事务、重试与外部副作用优化，同时落实编码与XML SQL规范。
## 任务目标 请在当前目标工程中，完成本次范围内的 Java 性能、幂等与可靠性优化。必须先查证瓶颈，再完成代码修改和验证；不能只提出缓存、异步或加线程的建议。资料可从工程获得时自行读取，仅对影响正确性的关键缺口提问，继续完成其余已授权工作。 在现有授权范围内完成实际改动和验证；缺少外部条件时先完成可独立实现的部分，不能只停留在计划。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 优化链路：优先选择当前对话指出的慢接口或重复执行问题；未指定时从当前 Java 工程的已有慢调用证据、循环访问和写操作中识别一条可定位、可验证的链路，说明选择依据后先完成该链路。 工程与性能资料：读取当前仓库的模块依赖、入口、SQL、事务、重试、已有测试和可用性能记录，自动确认版本、格式规则与验证命令，不要求用户重新填写这些信息。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 沿入口追踪 SQL 与远程调用次数、循环取数、事务和锁范围，以及下游连接与线程资源。 - 读取业务幂等键、唯一约束、处理中记录、重试接管和结果查询实现，核对权限与租户范围。 - 检查实际 Maven 或 Gradle、MyBatis XML、数据库迁移、静态检查和格式配置。 - 查找代表性测试数据、已有压测结果、延迟与资源指标；没有实测时识别能够本地复现的访问模式。 ### 可采用的默认处理 - 沿用现有版本、接口契约与中间件；先修正有代码或测试证据的重复工作，不默认加缓存、异步或线程。 - 缺负载数据时先记录调用次数、批量边界和可测指标，性能收益保留待测，不编造吞吐或最优参数。 - 保留稳定数据库编码与旧数据语义，XML SQL 和局部格式规则按原约束实施，限制本轮改动范围。 ### 必须有依据的事项 - 同一业务意图的判定、同键异参处理或处理中接管规则没有可信依据时，不自行改变幂等业务结果。 - 批量改造会改变事务原子性、顺序、权限或外部副作用，而其业务容忍度无法确定时，暂停该项语义变更。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 无工程时交付循环批量化与幂等状态的可执行示例、测量清单和故障用例，标明示例假设及尚未实施到项目。 - 缺运行环境时完成可执行的编译、静态检查和隔离回归，给出按同一数据与负载比较前后的测量步骤。 ## 执行要求 以实际运行版本和部署约束为准，不默认升级框架或引入中间件。SQL全部放XML、编码与字典分工等是本项目硬约束；MyBatis支持SQL注解，本项目明确禁用。 1. 只读确定范围和基线。确认仓库分支、未提交改动、真实入口及调用链，记录权限租户、返回字段、顺序分页、事务原子性和错误语义。保护无关改动，先运行已有相关检查，区分原有故障。用代表性数据和请求记录SQL/远程调用次数、延迟分位、吞吐、错误、连接等待、CPU与内存，写明并发、样本、冷热状态和时间窗口。缺少监控只能标记假设，不能虚构瓶颈或收益。 2. 按证据选择最小改动。区分数据库扫描、N+1、远程等待、锁竞争、重复计算和大对象分配，列出根因证据、候选方案、代价和可回退点。优先修正错误访问模式与重复工作，不为局部变快改变业务结果或降低权限校验，不一次叠加多个难以归因的优化。涉及架构或接口变化时明确新旧兼容，先完成范围内可验证的修改。 3. 优化for中的数据访问。定位循环查库、远程调用、懒加载和对象转换暗含的请求，按租户及业务键去重批量取数，再使用有界映射组装；没有批量接口时评估有界并发及下游限制，不能改成无界并行。控制单批参数量、页大小、事务时长和内存，避免巨大IN与全表加载。保留重复项、顺序、缺失关联和错误语义；联表注意行数膨胀与分页计数，跨页修改要考虑稳定游标与并发变化。for清晰就保留，不一律改Stream或parallelStream。 4. SQL统一落在XML Mapper。MyBatis的全部SQL从Java业务层、SQL注解、Provider、字符串或SQL Builder/Wrapper中迁入XML，Mapper接口只留契约和必要参数绑定；核对namespace、参数、resultMap、主键回填和加载。值使用#{参数}绑定，动态列、表和排序方向须服务端白名单并由XML选择固定片段，禁止将用户值送入美元符文本替换。空集合、全空更新和条件缺失不能变成全表操作。依据真实执行计划和数据分布调整查询及索引，不能仅以语法或扫描告警判断性能。 5. 将幂等设计落实到持久化。明确“同一次业务意图”的业务键、租户与操作范围、参数摘要和保留期，用数据库唯一约束或等效原子条件及事务争用执行资格，先查后插只能辅助。区分首次执行、处理中、成功、确定失败和结果不明；同键同内容按契约返回既有结果，同键不同内容拒绝冲突。并发唯一冲突须查询归属正确的记录，先核对当前事务是否仍可用，不吞异常后假成功；缓存锁和前端防抖都不能替代业务唯一性。 6. 处理超时、重试及接管。客户端超时不证明服务端未提交，优先用业务键查询最终状态，未经确认不得换新键重做。按失败类型定义可重试项、次数、退避和总时限；死锁等重试要重建正确事务边界，状态不明先对账。处理中记录须有合法接管条件，避免超时后旧执行者仍能写入；必要时用版本或执行令牌拒绝过期持有者。跨租户查询及结果回放都要重新验证权限。 7. 验证事务和外部副作用。核对代理方式、传播、事务管理器、锁范围及回滚规则；默认代理模式下自调用不会触发被调方法的事务语义，但可能仍处于外层事务。受检异常是否回滚按配置验证，不让catch吞掉失败。数据库事务不覆盖远程扣款、发信或消息投递；按已有能力使用下游业务幂等键、结果查询、可靠事件或补偿，并覆盖本地提交与外部成功不同步的窗口。afterCommit回调不等于可靠投递，不能承诺跨系统天然恰好一次。 8. 控制资源和失败放大。避免持数据库锁等待慢远程响应；减少事务范围前先保持业务原子性，不能随意拆批提交。线程池、队列、连接池、超时和并发上限按负载及下游容量设界，正确传播并清理租户和追踪上下文，处理中断与取消。缓存必须说明权限维度、更新失效与一致性要求，不能把数据库故障降级成成功空结果；优化不能把压力转嫁给下游而掩盖本地指标。 9. 同步完成编码与结构标准化。消除状态、类型、阈值和业务字符串魔法值；稳定有限的数据库编码用显式code的enum，核对序列化和TypeHandler，禁止ordinal持久化及随名称变化改库值。可配置字典数据库为唯一来源，不手工重复维护enum加字典；常量和配置各按语义归属。保留旧值、停用值和未知编码，读取可标未知但不篡改原值，写入或状态迁移需受控校验。Controller管协议入口，Service管领域和事务，Mapper管持久化；DTO、DO、VO明确转换，禁止越权批量赋值。 10. 复用、清理与防御并行。只抽取已证实共性，纯通用函数才入Util，领域逻辑留领域Service，不建万能Util或无必要的泛型框架。检查null拆箱、空集合、重复键、金额精度、时间边界与不可信参数；异常保留原因和业务标识，脱敏记录且不假成功。删除无用及重复代码前核对反射、XML、SPI、扫描、序列化和配置引用。规整命名结构，为类、关键字段、枚举及方法写清晰Javadoc和业务原因注释；新增表全部字段及新增字段须用COMMENT或对应语法补齐中文数据库注释，详细说明含义、单位、编码、空值和默认值。格式仅用既有规则及单一工具处理本轮文件，禁止整仓无关格式化，不生成无关Markdown。 11. 用实际结果验收。运行编译、现有检查和必要回归，在隔离验证环境覆盖重复提交、同键异参、多线程争用、越权租户、未知编码、空输入、批量边界、事务回滚、提交后响应丢失、外部成功但本地未确认、重试及过期接管。既核对响应也核对业务记录、金额和副作用次数，禁止仅断言HTTP成功。记录实际执行与未覆盖项；没有执行条件时完成可执行检查，不填写通过。 ## 交付与验收 对比并交付。在相同数据、并发、负载与观测窗口下对比修改前后延迟、吞吐、错误、查询次数和资源，不只报一次平均耗时；确认业务结果一致、尾延迟和下游未恶化。输出已改文件及原因、基线与证据、批量边界、幂等状态与唯一约束方案、事务及外部副作用矩阵、验证记录、回退和剩余风险。新增持久化结构使用项目既有迁移方式并验证历史重复数据与兼容回退；未实测不能声称性能提升，交付实际完成的修改而非待办方案。 格式落地补充：工程缺少成文配置时，以同模块稳定风格制定一套最小规则，明确空格、缩进、换行、空行、导入顺序及成员组织，用兼容的格式化或静态检查工具固化到现有构建。列出实际采用的规则和检查入口，不能只口头要求代码整齐，也不能额外引入相互冲突的格式工具。 ### 本条完成检查 - 交付实际修改及证据，说明 SQL/远程调用、批量内存、事务和幂等约束如何变化。 - 验证同键异参、并发争用、超时未知、过期接管、租户越权和外部副作用次数，不仅检查 HTTP 成功。 - 有实测才比较延迟、吞吐和资源；没有实测则明确未证实收益，并保留回退与历史数据兼容说明。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方依据（2026-09-08核验，具体能力按项目版本确认，不代表完整企业内部规范）： - 阿里巴巴《P3C-PMD 公开编码规则》：https://github.com/alibaba/p3c/blob/master/p3c-pmd/README.md - MyBatis《MyBatis 3：Mapper XML Files》：https://mybatis.org/mybatis-3/sqlmap-xml.html - MyBatis《MyBatis 3：Dynamic SQL》：https://mybatis.org/mybatis-3/dynamic-sql.html - Spring《Spring Framework：Using @Transactional》：https://docs.spring.io/spring-framework/reference/data-access/transaction/declarative/annotations.html - Spring《Spring Framework：Rolling Back a Declarative Transaction》：https://docs.spring.io/spring-framework/reference/data-access/transaction/declarative/rolling-back.html 收录核验（2026-09-08）：已核对公开资料和本次项目要求的覆盖范围；尚未使用真实项目执行本模板或进行模型效果评测。具体改动、性能和回归结果须在目标工程中验证。
对已有 Java 工程完成结构分层、业务编码、XML SQL、复用和清理，并验证行为兼容。
## 任务目标 请在当前目标工程中，完成本次模块范围内的 Java 结构与编码规范重构。目标是让职责、数据模型、SQL和业务规则清楚一致，并实际修改代码和验证；不要只交审查清单或示例。缺少资料先读取工程，只有影响正确性且无法从工程确定的事项才提问，其余已授权工作继续推进。 在现有授权范围内完成实际改动和验证；缺少外部条件时先完成可独立实现的部分，不能只停留在计划。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 重构模块：从当前对话、正在修改的文件与 Java 模块入口定位目标；未指定时选择一条包含 Controller、Service、Mapper 和实体转换的完整业务链作为首批范围，避免默认整仓重构。 工程与契约资料：读取当前仓库的接口、调用方、枚举字典、XML、迁移和测试，以及同模块稳定代码与格式配置，自动确认版本和已有行为。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 核对分支与未提交修改，并追踪目标入口到 DTO、Service、Mapper/XML 和表结构。 - 盘点状态编码、数据库字典、TypeHandler、序列化字段及历史值处理。 - 检索 SQL 注解、Provider、字符串或 Wrapper，以及反射、SPI、XML、扫描和配置引用。 - 读取既有编译检查、接口回归、数据库集成测试和单一格式工具的入口。 ### 可采用的默认处理 - 保持公共接口、持久化编码、权限和事务行为；不升级框架，不为所有类新增接口或强行改 Stream。 - 已有格式配置优先，缺少配置时沿用同模块稳定风格，只规整本轮文件并用一个兼容工具固化。 - 先落实职责与 SQL 归位等有依据的重构；无法解释的旧编码保留原值，不能映射为首项或零值。 ### 必须有依据的事项 - 状态或字典的权威来源、旧编码含义及迁移映射存在冲突时，不自行更改存量数据的业务解释。 - 拟删除或合并的代码涉及无法确认的外部契约、权限字段或副作用时，不把无静态引用当成可删除证据。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有工程时交付分层与 XML Mapper 的成套示例、枚举字典归属表和旧编码兼容测试样例，说明未执行项目重构。 - 缺数据库环境时完成可执行的代码检查，并交付参数映射、方言、资源加载和历史值验证用例，不宣称 SQL 已验证。 ## 执行要求 按项目真实 Java、Spring、MyBatis 及数据库版本实施，不借机升级技术栈。XML限定、枚举与字典分工等属于本项目硬约束。MyBatis允许注解，本项目禁止用该能力承载SQL。 1. 先只读建立范围和基线。确认仓库、分支、未提交改动及模块依赖，从入口沿 Controller、Service、Mapper/XML、表结构追踪一条真实业务链，核对已有校验和测试。记录接口字段、错误码、排序分页、事务和数据权限契约；保留无关改动，不重置工作区。给出分批修改顺序后实施，基线失败与本轮引入失败分开记录。 2. 消除业务魔法值。盘点状态、类型、阈值、标识和业务字符串，明确语义及唯一来源。稳定且有限的数据库业务编码使用带显式code和说明的enum，读写绑定实际code，禁止ordinal持久化，也不以枚举名称变动隐式改库值；核对序列化与TypeHandler。可配置字典以数据库为唯一来源，不为同一值再手工维护一套enum。一般固定常量给出语义名称，阈值按业务决定是否配置化，不把每个数字都建成枚举。 3. 兼容旧数据与未知编码。核对历史值、空值、已停用字典项和灰度期间的新编码；读取时保留原编码并按契约展示未知或停用状态，不悄悄映射成零、首项或其他有效业务状态。写入和状态迁移要验证允许范围，无法安全执行时明确拒绝。若需迁移，说明旧值到新值映射、并行版本兼容与回退，不能仅改Java类型让历史记录读不出来。 4. 整理分层和复用。Controller负责协议、参数及身份入口，Service负责业务规则和事务，Mapper负责持久化；DTO承接输入，DO对应持久化模型，VO按接口契约输出，明确转换及允许写入字段，防止客户端覆盖租户、审计或权限字段。先找真实共同语义再复用；只有无业务状态和外部依赖的纯通用函数才抽Util，领域计算和业务校验留在领域Service。禁止万能Util、为了行数拆碎方法、只有一个用途却搭泛型框架；不强制所有类新增接口。 5. 将MyBatis执行的全部SQL集中到XML Mapper。Java业务层和Mapper接口不承载SQL，不用SQL注解、Provider、Java字符串、SQL Builder或Wrapper拼接绕过限制；Mapper接口保留方法与必要参数绑定。同步核对namespace、方法id、参数名、resultMap、主键回填及资源打包。值参数使用#{参数}绑定；动态列、表及排序方向只允许服务端白名单并在XML选择固定片段，禁止用户输入直接进入美元符文本替换。可复用SQL片段须保持租户和业务过滤语义，迁移DDL沿用工程既有机制。 6. 保持循环和查询的业务含义。识别for及映射转换中的循环查库、远程调用和隐式懒加载N+1，按真实关联键先批量获取再组装；限制批次、分页和内存，不全量装入大表。保留结果顺序、重复项及缺失关联的语义，空集合不得导致XML过滤消失或全表更新。for清楚时保留for，不一律改成Stream或parallelStream；改变调用顺序与批量失败语义时补充相应验证。 7. 加固边界而不隐藏错误。权限和租户来自可信上下文，每次读写核对数据归属；批量查询和幂等结果回放同样不能越权。区分未传、显式null、空字符串、空集合和合法零值，防止拆箱空指针、金额精度或日期时区改变。异常保留原因和必要关联标识，日志脱敏且避免层层重复；不吞异常返回成功或空列表。事务按实际代理调用和回滚规则核验，自调用未触发新事务语义不等于外层必无事务。 8. 重构写操作时保住幂等和外部副作用。以业务键、租户范围、数据库唯一约束及事务保障同一意图只落一次业务结果，不能只靠先查后插、前端禁按钮或短期缓存。核对重复请求、并发、同键不同内容、超时结果不明与重试；不把超时当作失败直接重做。远程调用和消息不能假定随数据库事务回滚，按现有能力处理结果查询、可靠投递或补偿，不在结构重构中随意增加中间件。 9. 清理与规范同步落地。删除前检查静态引用、XML、反射、序列化、注解扫描、SPI、定时任务与配置约定；确认失效或重复才删，不能仅凭IDE灰色提示。按业务职责规整目录、依赖、命名和成员顺序；在类、关键字段、枚举及方法补充有意义的Javadoc，说明参数、返回、异常和业务限制，复杂分支注释解释原因而非复述代码，不编造作者日期。新增表的全部字段及新增字段须写入详细中文数据库注释，使用COMMENT或目标数据库对应语法，说明含义、单位、编码、空值及默认值语义。空格、换行、缩进和导入遵循既有规则及单一格式化工具，仅处理本轮文件，禁止无关整仓格式化。 10. 实际验证并收口。在每批修改后检查差异，运行受影响模块的编译、既有静态检查及必要测试；补足对契约变化有辨识力的回归，覆盖旧编码、未知编码、空输入、权限租户、批量边界、事务失败和重复请求。XML须验证资源加载、参数结果映射及真实数据库方言；仅编译不能证明SQL正确。环境不足时完成可执行部分并列明具体缺口，不把未运行、没有测试或仅人工阅读写成通过。 ## 交付与验收 交付格式：先说明完成的业务变化及保留的契约，再列修改文件与理由、枚举/字典/常量归属表、Java到XML迁移及分层对应关系、删除证据、实际验证结果和剩余风险。存在数据库变更时附项目已有格式的迁移与回退内容；没有实测就不给性能提升数字。交付已完成的代码，不生成无关Markdown文档，不将方案当作完成。 格式落地补充：工程缺少成文配置时，以同模块稳定风格制定一套最小规则，明确空格、缩进、换行、空行、导入顺序及成员组织，用兼容的格式化或静态检查工具固化到现有构建。列出实际采用的规则和检查入口，不能只口头要求代码整齐，也不能额外引入相互冲突的格式工具。 ### 本条完成检查 - 实际完成目标范围的结构整理、显式编码、XML SQL、DTO/DO/VO 边界和基于真实共性的复用。 - 删除有引用核对证据，新增字段具有详细中文注释，格式调整局限本轮文件。 - 记录编译及契约、旧编码、空值、权限、批量和事务回归，区分基线失败与本轮失败。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方依据（2026-09-08核验，仅采用相关条目，不代表完整企业内部规范）： - 阿里巴巴《P3C-PMD 公开编码规则》：https://github.com/alibaba/p3c/blob/master/p3c-pmd/README.md - MyBatis《MyBatis 3：Mapper XML Files》：https://mybatis.org/mybatis-3/sqlmap-xml.html - MyBatis《MyBatis 3：Dynamic SQL》：https://mybatis.org/mybatis-3/dynamic-sql.html - Spring《Spring Framework：Using @Transactional》：https://docs.spring.io/spring-framework/reference/data-access/transaction/declarative/annotations.html - Spring《Spring Framework：Rolling Back a Declarative Transaction》：https://docs.spring.io/spring-framework/reference/data-access/transaction/declarative/rolling-back.html 收录核验（2026-09-08）：已核对公开资料和本次项目要求的覆盖范围；尚未使用真实项目执行本模板或进行模型效果评测。具体改动、性能和回归结果须在目标工程中验证。
用于审批、工单、订单等状态流转，检查分支遗漏、重复提交、权限和持久化结果。
## 任务目标 请检查 Java 审批状态分支，并设计业务测试。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 审批流程：从当前需求或状态异常定位审批操作；留空时扫描现有审批 Controller、Service 和状态枚举，选择一条包含角色判断与状态写入的流程进行检查。 工程与审批规则：读取状态枚举、分支代码、权限定义、条件更新 SQL、现有用例及业务说明，自动还原实际迁移路径和版本。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 将入口操作、角色、对象归属和状态枚举对应到具体分支。 - 检查 switch 默认分支、复合条件顺序、未知和历史状态的处理。 - 追踪数据库条件更新、版本字段、唯一约束和外部动作，识别重复与并发覆盖。 - 对照现有测试和业务说明，分别记录代码现状与已确认规则。 ### 可采用的默认处理 - 默认只读检查和测试设计，给保持行为的最小整理建议，不自动新增审批步骤。 - 规则缺失时描述当前代码行为并标记待确认，不把现有分支直接当成已批准的业务规则。 - 未知状态不默认放行，权限、短路顺序和副作用按现有可信契约保留。 ### 必须有依据的事项 - 合法状态迁移、批准角色或对象归属规则没有可信依据时，不编造最终状态与越权测试的业务预期。 - 重复审批、撤回或并发竞争应由哪个操作生效不明确时，不擅自决定状态覆盖策略。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 有代码无规则时交付实际分支覆盖图、冲突与遗漏证据，以及业务预期待确认的测试表。 - 无工程时给状态迁移表、条件组合与重复并发测试模板，示例角色和状态仅用于说明方法。 ## 执行要求 适用范围：Java实现的有限业务状态与条件分支；状态迁移、权限和幂等策略以业务规则为准，不能按通用审批流程擅自补业务。 保持条件表达式易于理解，明确 switch 中未匹配情况的处理方式和各分支结束条件。 检查步骤： 1. 从业务资料整理状态迁移表，逐项记录起始状态、操作、角色、前置条件和终止状态；资料与代码冲突时列明两种行为并指出需要确认的事实。 2. 将每条合法迁移对应到实际代码路径，检查条件顺序是否遮蔽后续规则，以及缺少字段、未知枚举和历史状态会进入哪一条路径。 3. 为复合判断建立条件组合，找出权限、状态和数据归属之间的联动；不为追求代码简短而改变短路顺序或触发原先不会发生的副作用。 4. 检查重复提交和并发操作是否可能把状态覆盖回旧值，明确数据库约束或更新条件如何保障业务结果；未提供持久化代码时不得认定并发安全。 5. 给出保持行为的分支整理与需要业务决定的行为修正，分别列出改动；替换复杂判断时使用业务含义清楚的命名，不为了形式增加无用抽象。 6. 根据迁移表生成正常、拒绝、越权、重复、并发和异常测试，测试应观察数据库状态、外部动作次数与响应；说明哪些属于单元验证、哪些需真实集成环境。 ## 交付与验收 输出要求：依次提供状态迁移表、遗漏和冲突清单、最小代码修改、测试矩阵。每个测试使用“初始状态｜角色与归属｜操作及并发条件｜预期最终状态｜可观察证据”。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。 ### 本条完成检查 - 每条迁移列出起始状态、操作、角色、前提和目标状态，并关联代码证据。 - 区分保持行为的整理与需要业务决定的修正。 - 测试观察数据库最终状态、响应及副作用次数，持久化代码缺失时不声称并发安全。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 来源（核验日期：2026-09-08）： [阿里巴巴《P3C-PMD 官方公开规则》](https://github.com/alibaba/p3c/blob/master/p3c-pmd/README.md) 整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。
用于账期、日报、到期时间和跨年格式化，检查时间含义、时区转换和并发安全。
## 任务目标 请检查 Java 日期、时区转换与统计周期的边界。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 时间字段或周期：优先检查当前报表或日期异常；留空时从格式化、日期范围查询和统计分组中选择一条同时涉及接口与数据库的时间转换链。 工程与时间资料：读取字段类型、序列化与格式化配置、SQL 区间、数据库迁移和现有测试，自动核对 Java 版本、应用时区及已声明的业务周期。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 追踪前端、请求、Java 对象、数据库和导出的时间单位与表示方式。 - 检索日期格式、默认时区、秒毫秒转换、共享可变格式化器及系统当前时间调用。 - 读取日报月报 SQL 的上下界与业务统计分组，核对跨年周所属年和日历年。 - 查找字段注释、历史迁移、测试时钟和既有跨年、闰日用例。 ### 可采用的默认处理 - 默认只读检查，不更改全局时区或批量转换历史数据。 - 工程未声明业务时区时明确保留未知，示例使用显式标注的时区，不按中文环境推断统计口径。 - 用固定时间构造边界样例；候选区间可说明左闭右开优势，但不替换已有业务约定。 ### 必须有依据的事项 - 字段代表时间点、本地日期还是时长，以及既有历史数据的时区解释不明时，不自动转换或回填。 - 结算或统计周期、截点和首尾包含规则没有依据时，不自行制定报表预期。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 无工程时交付时间字段字典与跨年、月末、闰日、秒毫秒和多时区样例表。 - 缺业务周期时先检查格式与线程安全，区间样例列条件化结果并标明尚不能判定的统计口径。 ## 执行要求 适用范围：Java日期时间处理及数据库、前端之间的数据转换；使用java.time时需JDK8及以上，旧接口替换须保留既有时区与业务语义。 区分日期格式中的日历年与周所属年，检查旧格式化器的线程安全。 检查步骤： 1. 逐个识别字段表示的是时间点、本地日期、本地时间还是持续时长，注明单位与来源；账期、截止日期和事件发生时间不能仅凭字段名相互转换。 2. 追踪前端、接口、Java对象、数据库到导出文件的转换链，查找默认时区、隐式格式、秒与毫秒混用，以及同一字段在不同入口中使用不同解释。 3. 针对年末年初构造跨年样例，核对格式化、分组、排序和文件名称是否属于正确日历日期；仅在业务确实按周核算时使用周所属年语义。 4. 检查日报和月报的区间边界，明确定义起止是否包含，避免相邻周期重复或漏记；若涉及多个时区，补充本地一天对应的实际时间范围。 5. 核对日期工具对象是否被多线程共享、是否可变、是否依赖服务器当前时间；给出可注入业务时钟的改进范围，让测试不依赖执行当天。 6. 覆盖跨年、月末、闰日、时区转换、缺失时间及夏令时适用地区，分别验证展示和统计结果；若业务只使用固定时区，清楚说明无需扩展的范围。 ## 交付与验收 输出要求：输出时间字段字典、转换链、缺陷及修复建议、边界样例表。样例写明输入、业务时区、期望日期或区间以及实际结果，保留对历史数据解释和接口兼容性的说明。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。 ### 本条完成检查 - 转换链逐处说明类型、单位、格式和时区，不混同本地日期与时间点。 - 边界用例具有输入、业务时区、预期区间和实际结果。 - 修正建议说明历史数据与客户端兼容，未定义的统计业务不编造验收结果。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 来源（核验日期：2026-09-08）： [阿里巴巴《P3C-PMD 官方公开规则》](https://github.com/alibaba/p3c/blob/master/p3c-pmd/README.md) 整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。
用于订单、审核、库存等写操作，追踪异常、事务提交和外部副作用，避免失败被吞或状态半完成。
## 任务目标 请审查 Java 异常处理与事务结果的一致性。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 事务业务操作：从当前异常或写接口定位操作；留空时选择一条同时包含数据库写入与消息、缓存或远程调用的链路，核对用户看到成功的时点。 工程与异常资料：读取业务方法、调用方式、事务管理器与配置、异常类和全局处理器、数据库操作及已有故障测试，自动确定框架版本与回滚行为。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 按顺序追踪校验、数据库变更、消息、缓存和远程调用的可逆性。 - 核对事务代理、自调用、传播、管理器和 rollbackFor 等实际配置。 - 检查 catch、finally、提前返回和统一响应包装是否吞掉原始失败。 - 查找提交后任务、重试、补偿、查询与幂等处理及现有故障样例。 ### 可采用的默认处理 - 默认只读审查并提供最小修复片段，不改异常码、事务边界或执行外部副作用。 - 远程超时归为可能结果未知，不假设本地回滚能撤销外部操作。 - 框架行为以实际配置和调用链为准，缺运行证据时将回滚效果列为待测。 ### 必须有依据的事项 - 用户可见成功的业务定义、允许的部分完成或补偿结果不明确时，不自行把失败转换成成功。 - 外部动作能否查询、撤销或幂等重试的契约未知时，不设计会重复扣款或重复履约的恢复动作。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 无工程时交付按失败位置划分的事务结果矩阵和可控故障测试样例。 - 有代码无环境时输出异常传播与事务边界证据，列出核对最终数据和副作用次数的执行步骤。 ## 执行要求 适用范围：Java业务写操作及显式或框架管理的数据库事务；回滚条件必须核对实际框架配置，远程调用和消息不会自动随本地数据库回滚。 结合代码上下文检查异常后的回滚；注意 finally 中的返回可能遮蔽原有结果。 检查步骤： 1. 以一个真实业务操作为单位，按顺序列出校验、数据库变更、消息、缓存和远程请求，标明每个步骤的可逆性，以及用户看见成功的确切时点。 2. 核对事务边界、调用方式和异常到达的位置，分别模拟校验失败、数据库失败、外部超时及运行时异常；不要只看到事务注解就认定回滚一定生效。 3. 检查异常捕获后是否继续执行、改写返回值或丢失原因，区分可以转成业务结果的失败与必须向上交付的技术失败，保留定位问题所需的最少上下文。 4. 对数据库已提交而外部动作失败的情况明确结果，评估幂等重试、补偿和状态对账是否能恢复；对外部成功但响应超时的情况标记结果未知，避免直接重复副作用。 5. 提出能保留现有契约的最小修改，说明异常类型、返回码和事务配置如何协同；只给项目适用的机制，不为了套用模式拆分无必要的微服务。 6. 用可控故障点验证关键步骤，核对数据库最终状态、外部动作次数及用户响应；列出未覆盖的网络分区或并发场景，以及上线后的异常监测和补偿入口。 ## 交付与验收 输出要求：按业务步骤表、异常传播图的文字说明、问题清单、修复片段和故障用例交付。每个用例必须包含初始状态、注入故障、最终数据和预期响应，不能用“未报错”代替一致性结论。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。 ### 本条完成检查 - 每个风险关联业务步骤、异常位置、事务结果及用户响应。 - 修复建议保留现有契约并解释数据库提交与外部动作不同步的窗口。 - 用例包含初始状态、故障点、最终数据与响应，不以未报错判定一致性。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 来源（核验日期：2026-09-08）： [阿里巴巴《P3C-PMD 官方公开规则》](https://github.com/alibaba/p3c/blob/master/p3c-pmd/README.md) 整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。
排查线程复用导致的用户、租户和请求上下文串用，覆盖异步传递与异常清理。
## 任务目标 请检查 Java ThreadLocal 上下文传递及租户隔离。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 上下文链路：从当前请求或异步任务定位上下文；留空时扫描自定义 ThreadLocal、过滤器和线程池，选择一条能追踪到数据库或缓存访问的复用线程链路。 工程与隔离资料：读取上下文类、身份过滤器、任务包装、线程池、鉴权与持久化代码及相关测试，自动确认运行版本和实际存在的用户或租户维度。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 盘点上下文字段的可信写入来源、读取消费者和清理位置。 - 追踪正常、异常、提前返回、重复分发及嵌套切换后的恢复。 - 核对异步提交时的取值快照、定时任务身份和工作线程清理责任。 - 将上下文追踪到 SQL 过滤与缓存 Key，读取已有连续任务隔离测试。 ### 可采用的默认处理 - 默认只读检查，不关闭权限过滤或新增项目不存在的租户模型。 - 缺上下文不默认使用上一次任务或管理员身份，具体拒绝方式沿用可信契约。 - 测试使用匿名用户和最小上下文字段，生命周期候选优先显式传参或受控包装。 ### 必须有依据的事项 - 用户、租户或组织的可信身份来源与合法数据访问范围不明时，不能认定隔离通过或自行制定默认身份。 - 定时或异步任务合法代表哪个主体执行不明时，不自动继承调用线程或全局管理员权限。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有工程时交付上下文生命周期表和同线程先后执行不同身份任务的隔离用例。 - 有上下文代码但无数据层时先指出残留路径，给 SQL 与缓存范围取证点，不宣称数据隔离已验证。 ## 执行要求 适用范围：使用ThreadLocal、请求上下文或线程池的Java项目；仅在项目实际存在租户模型时检查租户，不能凭空增加业务隔离维度。 在线程复用场景中，检查自定义 ThreadLocal 是否在使用结束后清理。 检查步骤： 1. 列出所有上下文字段的写入来源、读取位置和清理位置，标注由认证结果生成还是直接来自请求参数；明确客户端传入标识不能自行证明其访问权限。 2. 沿一次请求追踪正常、异常、提前返回和重复分发路径，检查每条路径结束时上下文状态；给出可能残留的位置和下一次请求受影响的具体业务操作。 3. 追踪异步提交、定时执行和回调，确认上下文是否需要传递、传递哪些最小字段、何时冻结取值；不能假定父线程数据自动正确到达工作线程。 4. 核对嵌套调用临时切换上下文后的恢复策略，以及工作线程原有值如何处理；提出显式传参或受控包装方案时说明兼容影响和清理责任。 5. 在相同线程连续处理两个不同用户或租户的任务，第二个任务分别设置有效、缺失和错误上下文，验证数据访问范围；异常完成后再执行同样序列。 6. 把定位结果追踪到数据库查询和缓存键，验证实际数据边界而非只观察日志；如果权限依据缺失，应报告无法判定，不声称通过隔离检查。 ## 交付与验收 输出要求：交付上下文生命周期表、越界场景、最小修复及隔离验证结果。风险表应写明残留字段、复用入口、可能访问的数据和证据，测试使用匿名样本并避免记录真实身份凭证。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。 ### 本条完成检查 - 风险说明残留字段、线程复用入口及可能访问的数据，并具有路径证据。 - 覆盖异常清理、嵌套恢复和异步传递，不只检查是否调用 remove。 - 验证第二个任务的有效、缺失与错误上下文对数据库和缓存的实际影响。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 来源（核验日期：2026-09-08）： [阿里巴巴《P3C-PMD 官方公开规则》](https://github.com/alibaba/p3c/blob/master/p3c-pmd/README.md) 整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。
用于导出、批量计算、外部调用等异步任务，审查资源边界、拒绝处理及任务结果可追踪性。
## 任务目标 请评审 Java 线程池容量和异步任务的可靠性。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 异步任务：从当前排队或任务失败问题选择执行器；留空时扫描自建线程池和 Spring 异步入口，优先检查共享池中具有业务副作用的任务。 工程与负载资料：读取执行器配置、任务代码、上下游资源、依赖与已有排队耗时指标和测试，自动判断平台线程、虚拟线程或其他调度方式。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 追踪任务来源、提交返回、排队、执行和完成通知，确认是否持久化。 - 核对核心线程、上限、队列、拒绝策略、线程名及所用版本的参数语义。 - 关联数据库连接、远程连接、锁和共享池任务，查找阻塞与相互拖慢的路径。 - 读取异常、取消、停机重启和重试处理，以及现有负载与完成率记录。 ### 可采用的默认处理 - 默认只读评审，不直接扩线程、改拒绝策略或重启服务。 - 没有到达率与耗时分布时给测量方式、容量公式和附假设候选，不设固定最优线程数。 - 虚拟线程和响应式任务按实际实现另列边界，不机械套用传统池规则。 ### 必须有依据的事项 - 任务是否允许丢失、接口何时算业务完成以及拒绝后用户应收到什么结果不明时，不默认静默丢弃或同步执行。 - 带副作用任务在超时、取消和重启后是否允许重试未定义时，不承诺可安全重复执行。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 无工程时提供任务可靠性分类、资源关系和容量估算表，以及排队满、下游慢和重启用例。 - 缺负载环境时交付现有配置的静态风险及所需指标，不把未压测候选作为可直接采用参数。 ## 执行要求 适用范围：传统平台线程池与常见Spring异步执行器；虚拟线程、响应式调度器应另行评估，不机械套用旧线程数量建议。 明确线程池的资源边界，并为线程提供可识别的名称。 检查步骤： 1. 按业务列出任务来源、任务是否持久化、完成期限和失败归属，区分允许丢弃的通知与必须完成的业务任务；明确接口返回时任务处于哪个状态。 2. 绘制提交到执行完成的路径，标记线程池、排队、数据库连接、远程连接和锁等限制，找出共享池中可能互相拖慢的任务类型及调用方。 3. 根据到达率与耗时提出容量估算，写清假设、排队容忍时间和内存占用；资料不足时给测量方法与候选区间，不拍脑袋给固定线程数。 4. 逐项核对任务排队已满、执行超时、下游阻塞和提交失败时的行为，说明拒绝处理是否会让请求线程长时间阻塞、任务静默丢失或产生重复执行。 5. 检查任务异常、取消、应用退出和重新启动后的状态，验证调用者能否获知失败；若业务要求可靠执行，给出持久化任务与补偿的边界。 6. 设计平稳负载、突发负载、下游变慢及停机四组验证，采集排队时间、执行时间、完成率、拒绝数和资源占用；根据证据逐项调整，保留回退配置。 ## 交付与验收 输出要求：输出任务分类、资源关系、参数建议表、失败处理矩阵及验证计划。参数建议必须含当前值、依据、候选值、预期影响和回退条件，不把未压测值写成最优配置。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。 ### 本条完成检查 - 任务分类明确完成期限、失败归属、持久化与丢失边界。 - 参数建议关联当前值、资源上限、推导条件及拒绝影响。 - 验证排队、完成、拒绝、异常和重启后的任务结果，未测容量保持待验证。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 来源（核验日期：2026-09-08）： [阿里巴巴《P3C-PMD 官方公开规则》](https://github.com/alibaba/p3c/blob/master/p3c-pmd/README.md) 整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。
用于批量导入、分页、筛选和去重代码，检查集合共享、视图修改、遍历变更及内存边界。
## 任务目标 请审查 Java 集合视图、转换与批量处理代码。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 集合处理链：优先检查当前集合异常或批量接口；留空时从切片、数组转换、去重与批量组装代码选择一条存在共享或变更行为的处理链。 工程与数据样例：读取集合创建和消费者、接口输入、业务键、分页与并发代码、依赖版本和现有边界测试，自动归纳数据规模证据。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 追踪原集合、subList 等视图、独立副本与缓存引用的拥有关系。 - 检查数组与列表转换、增删替换、遍历修改和对象加入后再变更的行为。 - 核对去重键、排序、重复项保留及分页计数的实际契约。 - 读取批次边界、全量加载、中间副本及并发共享路径，核对 JDK 与集合库能力。 ### 可采用的默认处理 - 默认只读给最小替换建议，不统一改 Stream、并行集合或不可变类型。 - 没有业务去重和顺序定义时保留输入顺序与重复语义，不按对象名称猜业务键。 - 没有规模记录时对持有副本和峰值内存列计算条件，不虚构耗时。 ### 必须有依据的事项 - 业务顺序、重复项或缺失关联应如何处理不明时，不选择会改变输出的去重或批量策略。 - 共享集合是否允许实时可见变更及复合操作原子性不明确时，不以换集合类决定并发语义。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 无工程时交付视图与副本、转换及遍历变更的可运行边界样例和关系说明。 - 无大规模数据时给批次与内存估算模板，列空集合、重复、空元素、源变更和并发验证条件。 ## 执行要求 适用范围：使用Java集合的业务模块；不可变集合工厂、Stream及第三方集合的能力需匹配JDK与依赖版本。 核对集合视图与原集合的关联，以及具体集合对遍历修改和数组转换的支持。 检查步骤： 1. 标出每个集合的创建者、拥有者、读写方和生命周期，区分原始数据、分页视图、独立副本和缓存引用；指出在哪一层修改可能影响另外一个业务调用。 2. 用真实调用路径检查分页切片、数组转列表和列表转数组，分别验证能否增加、删除、替换及强制转换；将依赖具体实现的假设改为明确契约。 3. 检查筛选与去重是否保持业务要求的稳定顺序，以及重复记录按哪个业务键识别；若对象在加入集合后继续修改，核对后续查找和结果是否仍正确。 4. 评估批量规模，区分一次全量加载、分批读取和流式处理；估算同时持有的数据副本与中间结果，容量结论注明来源，不根据循环层数臆测实际耗时。 5. 检查并发共享是否存在可见性或写入冲突，说明快照、加锁、分段处理等候选方案各自改变的语义；不要仅更换集合类就宣称业务操作整体原子。 6. 提供覆盖空集合、单元素、重复、空元素、源集合变更及大批量输入的验证用例；并发场景必须定义可重复观察的结果，记录未执行的压力验证。 ## 交付与验收 输出要求：交付集合关系说明、缺陷表、最小替换代码和验证矩阵。每处修改说明是否保留原有顺序、重复项和共享语义，另外列出峰值内存估算的假设与需要采集的指标。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。 ### 本条完成检查 - 每项缺陷说明创建者、修改者、触发输入和受影响调用。 - 替换建议明确是否保留顺序、重复项、共享关系和批量失败语义。 - 验证包含源集合变更与边界输入，容量和并发结论注明实际执行范围。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 来源（核验日期：2026-09-08）： [阿里巴巴《P3C-PMD 官方公开规则》](https://github.com/alibaba/p3c/blob/master/p3c-pmd/README.md) 整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。
检查DTO、数据库查询、远程调用和集合中的空值传播，避免默认值掩盖未知状态。
## 任务目标 请排查 Java 空值传播与包装类型的边界问题。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 空值字段链：从当前空指针或字段异常定位输入；留空时优先扫描可空包装类型参与算术、判断和返回的位置，选择一条能追踪到请求或数据库来源的链路。 工程与字段资料：读取 DTO、实体、DDL、映射、远程接口契约和边界用例，自动确认字段可空性、序列化与实际 JDK 依赖。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 沿缺字段、显式 null、无记录和外部不完整响应追踪到业务运算及展示。 - 检索包装类型比较、自动拆箱、集合元素及默认值转换。 - 核对数据库可空、入口校验、字段注释和响应模型是否一致。 - 读取对象值相同但实例不同、正常值与空值的既有测试。 ### 可采用的默认处理 - 默认只读排查并给修复片段，不批量把 null 改为零或空字符串。 - 业务含义缺失时保留未知与合法零值的区别，已有契约优先。 - 对无源码依赖按声明契约和输入样例分析，不编造其内部返回保证。 ### 必须有依据的事项 - 空值代表未知、未提供、关闭还是无记录缺少业务定义时，不替用户决定默认值或改变公共字段类型。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 无工程时交付空值传播与包装比较的独立测试样例，以及入口、映射和运算层的校验选择表。 - 仅有字段定义时先完成空值语义疑点和边界请求矩阵，触发路径保留待验证。 ## 执行要求 适用范围：使用Java对象、包装类型和常见持久化框架的业务代码；具体映射和校验行为以JDK与依赖版本为准。 检查包装值比较和自动拆箱中的空值风险，不假定远程调用或数据库查询总能返回值。 检查步骤： 1. 画出目标字段从请求、查询或远程响应到业务计算、持久化及展示的传播路径，区分未提供、未知、无记录、零值和空字符串，不能把所有情况自动合并。 2. 找出可空值参与比较、算术、条件判断、方法返回和集合操作的位置，为每个疑点指出确切输入及可能结果；对无源码依赖只列待验证的接口契约。 3. 检查默认值是否改变业务事实，例如未知计数被展示成零、未提交配置被当成关闭；将需要拒绝输入、保留为空或业务兜底的场景分别列出理由。 4. 对对象比较与集合元素给出包含空值、相同值和不同实例的样例，检查现有结果是否稳定；避免只针对小范围数值验证而遗漏实际业务标识。 5. 提出最小修复，明确校验应放在入口、转换层还是计算前；说明对已有数据和外部调用方的影响，不为消除异常随意改变公共字段类型或业务默认值。 6. 设计能区分修复前后行为的测试，覆盖缺字段、显式空值、查询无记录、远程返回不完整和混合集合；同时保留正常业务样例，记录真正执行的结果。 ## 交付与验收 输出要求：先给空值语义表，再给风险清单、修正代码与测试矩阵。每个风险须给出“来源字段｜传播路径｜触发输入｜错误业务结果”，无法重现的项目保持待验证状态。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。 ### 本条完成检查 - 风险表包含来源字段、传播路径、触发输入和错误业务结果。 - 修复建议说明校验位置、旧数据与调用方兼容性，不以消除异常掩盖未知事实。 - 用例覆盖缺字段、显式空值、无记录、外部缺项与混合集合，并保留正常样例。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 来源（核验日期：2026-09-08）： [阿里巴巴《P3C-PMD 官方公开规则》](https://github.com/alibaba/p3c/blob/master/p3c-pmd/README.md) 整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。
用于新接口开发和前后端联调，检查字段含义、空值、枚举、序列化兼容及接口说明。
## 任务目标 请评审 Java 接口契约与 DTO 字段。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 接口或业务操作：优先使用当前需求或接口变更；留空时从现有 Controller/RPC 入口与调用方选取一条实际业务操作，连同 DTO、响应和异常完成契约评审。 工程与接口资料：读取接口定义、DTO/VO、服务方法、序列化和校验配置、前端或 RPC 调用样例及既有测试，自动确认框架与 Java 模型类型。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 追踪发起角色、前提、数据对象、成功时点和异常到接口返回的映射。 - 核对字段名称、类型、长度、单位、必填条件、枚举、空值及脱敏。 - 检查 DTO 到 Service 到 VO 的转换、可写字段和实际 JSON，识别 record 或特殊模型。 - 读取客户端兼容、分页排序、重复提交、对象归属及真实租户边界的实现与样例。 ### 可采用的默认处理 - 默认只读评审，给最小契约修正示例，不直接修改公共字段和错误码。 - 已有客户端实际使用方式优先纳入兼容评估，不把传统 JavaBean 规则套到所有模型。 - 业务说明不足时分别记录代码现状和待确认语义，不把 HTTP 成功当作异步业务完成。 ### 必须有依据的事项 - 金额单位、时间含义、状态或异步完成标准未定义时，不编造字段默认值与业务验收结果。 - 合法操作角色、对象归属或旧客户端兼容约束存在冲突时，不自行放宽写入权限或破坏公共契约。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 无工程时交付接口与字段字典、有效请求和边界请求的契约模板，未定义的业务结果明确标注。 - 只有接口样例时完成字段一致性与兼容风险审查，列出需要从实现确认的转换和权限点。 ## 执行要求 适用范围：常规Java后端的HTTP或RPC接口；先核对JDK与框架版本，不将传统JavaBean约定直接套用于record或特殊序列化模型。 让接口说明覆盖输入、返回及异常，使用能准确表达含义的名称。 检查步骤： 1. 从业务需求列出操作对象、发起角色、前置条件、成功状态和失败状态，逐项对应到接口；不能用接口返回成功替代业务实际完成，异步任务要明确状态查询入口。 2. 建立请求与响应字段字典，逐个核对名称、类型、长度、单位、必填条件、空值含义、枚举和脱敏要求；遇到金额、时区、状态码等缺少定义时指出具体缺口。 3. 追踪DTO到业务方法再到响应对象的转换，检查重命名、漏传、默认值和字段覆盖；对布尔属性核对实际序列化结果，并用现有客户端样例验证兼容性。 4. 检查路径、查询参数与请求体是否承担清晰职责，列出重复提交、分页、排序、越权对象访问等边界；只在项目确有多租户时核对租户字段的可信来源。 5. 补齐接口注释需要表达的业务规则，给出一组有效请求和至少三组边界请求，响应需包含可处理的业务信息；不要向用户暴露堆栈或内部连接信息。 6. 将需求、接口、字段和验收用例逐条关联，区分新增接口与兼容改动；评估旧客户端在字段缺失、增加或枚举扩展时的行为，并给出分阶段联调顺序。 ## 交付与验收 输出要求：依次给出接口清单、字段字典、问题表、最小修改示例和联调用例。问题表使用“位置｜触发条件｜实际影响｜修正建议｜验证方式”，用例写明请求、期望业务状态及期望响应。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。 ### 本条完成检查 - 需求、接口、字段和用例能够对应，问题具有位置、触发条件、影响和验证方式。 - 检查实际序列化、字段覆盖与越权写入，说明新增和兼容改动的区别。 - 至少给有效请求及三类边界请求，分别标明预期业务状态与响应，未验证行为不写通过。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 来源（核验日期：2026-09-08）： [阿里巴巴《P3C-PMD 官方公开规则》](https://github.com/alibaba/p3c/blob/master/p3c-pmd/README.md) 整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。
