接入易错点

 创建投放计划前须接入商品券，并至少完成商家名片或品牌门店之一，线下核销须补齐可用门店

 说明：摇优惠不是只对接发券接口的单点能力，创建投放计划前必须先接入商品券能力，并至少接入商家名片与品牌门店其中之一；运营规范另要求线下核销（到店自提、到店核销）的活动配置可支持微信支付的可用门店信息，且录入的门店名称须与品牌名称一致。
正确应该怎么做：① 按摇一摇有优惠开发接入准备完成品牌开通与产品能力接入，接入商品券能力并打通创建商品券、发放、回调、核销链路；② 在品牌经营平台完成商家名片配置，或通过品牌门店 API / 品牌经营平台创建品牌门店（二选一）；③ 线下核销场景补齐可支持微信支付的可用门店，门店名称与品牌名称保持一致，线上核销链路若依赖线上门店距离配送，同样需按运营要求添加门店；④ 确不适用线下品牌门店的（如纯线上核销），先与行业运营确认改按城市投放等方案，再提交审核。
典型反例：认为只需调用一次发券接口即可上线摇一摇发券，跳过商品券与名片/门店能力接入直接申请创建投放计划；线上核销链路的品牌认为「品牌门店只适用于线下门店」，既未配置商家名片也未创建门店即提交审核。
见 4016060309-开发接入准备、4016081508-摇一摇有优惠开发指引、4017418651-摇一摇有优惠常见问题、4017294555-运营规则、4016080147-权限申请、4016626206-品牌门店开发指引 

 前置能力未接入时投放计划无法创建或被审核驳回（驳回原因「需配置门店」），摇一摇发券活动无法上线，联调排期整体后延。

 品牌经营新增能力须联系微信支付运营按品牌 id 单独开通权限后再调用

 说明：品牌并非默认拥有全部品牌经营接口权限，联合投放、人群包自动覆盖等新增能力需联系微信支付运营人员申请开通，并在品牌维度完成权限配置；联合投放目前仅支持摇优惠且仍处于内测阶段，是否扩展到其他投放方式未定。未开通权限时调用相关接口会返回无权限报错。
正确应该怎么做：① 接入前先与对接的微信支付运营确认目标能力是否已在品牌维度开通，并提供品牌 id，未开通的联系运营申请开通；② 待运营确认「权限已配置」后再发起接口调用；③ 调用返回 HTTP 403 / NO_AUTH 或 268589041 时，保留应答头中的 Request-ID，连同品牌 id 一并提供给运营申请授权；④ 不要将联合投放用于摇优惠以外的投放场景。
典型反例：按接口文档完成开发后直接调用，未确认品牌维度的权限是否已配置。
见 4024833908-联合投放开发指引、4024833914-联合投放产品介绍、4016060309-开发接入准备、4016080147-权限申请、4023120617-摇一摇有优惠错误码、4015782176-摇一摇有优惠产品介绍 

 调用返回 code=-1、StatusCode: 403、{"code":"NO_AUTH","message":"权限异常"} 或 268589041 / NO_AUTH「没有权限设置联合投放」，提示「人群包上传失败，微信支付API访问失败」，人群包与计划映射无法下发，定投与联合投放活动无法配置。

 手机号发券能力须经运营评估开通并灰度放量，不可直接全量放开

 说明：手机号发券（领券授权手机号）目前仅开放给少量商户试行，需联系微信支付行业运营评估开通，且上线需先完成测试环境验收再逐步灰度放量。
正确应该怎么做：① 联系微信支付行业运营评估并走开通流程，不要在未开通前按已开通实现；② 在测试环境完成手机号领券链路验收（按微信侧要求提交测试微信号及其对应的一笔交易订单号申请加白）；③ 验收通过后按灰度节奏逐步放量，不要一次性全量；④ 按回调 phone_number 实现按手机号发券与兜底逻辑。
典型反例：认为"只是在原基础上多传手机号不会产生影响"，未做测试验收直接全量放开。
见 4016950448-商品券（单券）常见问题、4015755761-商品券回调通知 

 能力未开通或未灰度前调用不生效，用户侧与商户侧手机号不一致导致发券资格被挂起、券迟迟不到账，引发客诉。

 下单 AppID 关联品牌后须等到次日生效再用于投放与下单

 说明：品牌与下单 AppID 完成关联（平台审核通过且 AppID 管理员授权确认）后，关联关系并非即时生效，官方文档明确「品牌经营平台完成关联后，将在次日生效」；品牌关联 AppID 后还需约 2~3 小时才能完成品牌下收款商户号的共享覆盖。
正确应该怎么做：① 品牌方登录品牌经营平台-账号管理-下单 AppID 管理，点击「关联 AppID」发起关联，关联异主体 AppID 时需填写 AppID 主体名称、选择主体关系类型并上传关系证明材料；② 平台审核通过后，由 AppID 管理员在微信公众平台（小程序/公众号）或微信开放平台（移动应用）完成授权确认；③ 等到次日关联生效，并预留 2~3 小时商户号共享覆盖时间，再把该 AppID 用于摇一摇有优惠的投放与下单。
典型反例：后台已显示「绑定通过」的当天即按已生效状态创建投放计划或发起下单。
见 4016060309-开发接入准备、4016080147-权限申请 

 绑定当天相关操作仍返回同一报错，投放计划与下单链路调不通，活动无法按计划时间上线。

 一个商品券批次只能配置一个小程序 AppID，多小程序露出须建多个批次

 说明：批次的 usage_rule_display_info.mini_program_appid 为单个小程序 AppID，且该小程序须与品牌存在绑定关系；投放计划创建处没有直接关联多个小程序的配置项。品牌与 appid 为多对多绑定关系，一个品牌可关联多个 appid。
正确应该怎么做：① 需要在几个小程序露出，就创建几个商品券批次，每个批次分别绑定对应的小程序 AppID 并填写 mini_program_path；② 通过「品牌经营平台-账号管理-下单appid管理」关联 AppID，关联在次日生效；③ 券的使用（核销）方式用 coupon_usage_method_list 配置（MINI_PROGRAM/APP/PAYMENT_CODE/OFFLINE），注意投放计划暂不支持 OFFLINE 线下滴码核销。
见 4015736342-添加商品券批次、4017418651-摇一摇有优惠常见问题、4018984237-品牌、服务商、appid关联关系 

 券只能在单一小程序曝光，跨小程序引流方案无法实现；批次填写了未与品牌绑定的 AppID 会校验不通过。

 跨主体共享同一张券须按集团关联关系绑定 AppID 并完成审核授权

 说明：品牌与 AppID 为多对多绑定关系，一个品牌可关联多个 appid；集团与子公司主体不同时，绑定 AppID 可选择集团关联关系类型，上传股权证明、集团关系证明等材料，经平台审核并由 AppID 管理员在微信公众平台确认授权后完成关联。
正确应该怎么做：① 在品牌经营平台发起 AppID 关联，关系类型选择「集团关联关系」；② 上传股权证明、集团关系证明等证明材料；③ 等待平台审核，并通知 AppID 管理员登录微信公众平台确认授权，最终以材料审核结果为准。
见 4018984237-品牌、服务商、appid关联关系 

 品牌与子公司 AppID 无法建立绑定关系，同一张券无法在子公司小程序露出。

 商品券批次有效期须控制在一年以内，投放结束时间须早于批次到期时间

 说明：商品券批次的开始时间与结束时间间隔不能超过一年（批次有效期最长不超过 366 天），摇优惠场景建议批次可核销时间设置为不少于 5 天；商品券会随批次结束时间到期而直接失效，投放计划的结束时间需早于批次时间，投放计划活动时间未结束但所配置批次已失效或库存已发完时，投放计划会自动进入「已暂停」状态。
正确应该怎么做：① 创建商品券批次时按规则设置 available_begin_time / available_end_time，两者间隔控制在一年以内；② 摇优惠场景将批次可核销时间设置为不少于 5 天；③ 投放计划结束时间按「批次结束时间 −（领券后需等待天数 + 券生效后可用天数）− 1 天」的规则设置，未配置这两个字段时最长为「批次结束时间 − 1 天」；④ 投放期间监控批次有效期与库存，批次到期前及时续期或新建批次。
典型反例：投放计划仍在投放期内，但所配置的商品券批次已经到期失效，活动实际发不出券。
见 4016675772-商品券可核销时间规则说明（coupon_available_period）、4015736390-向用户发放商品券、4016080826-投放计划配置指引、4023120617-错误码、4017418651-常见问题 

 相关接口报错（如 268587486「券批次可核销时间不足5天」、268585145「投放需预留核销时间」），批次无法用于投放；已投放的活动因批次失效自动进入「已暂停」，客户端推荐券时因没有可投放的券而过滤掉该投放计划。

 次卡整体有效期由商户创建商品券时的可用天数决定，须按含领取当天的口径核对

 说明：次卡（多次优惠）由商户自行创建的商品券拼接而成，其整体周期取创建商品券时配置的可用天数（available_days，按「生效当天内有效填 1、生效后 2 天内有效填 2」的口径计算，从领取当天开始计算且含领取当天），不是微信侧设定或人工配置的周期；批次有效期最长不超过 366 天，券的金额与有效期创建后不可修改，只能新建批次调整。
正确应该怎么做：① 按期望的次卡周期（如 30 天/14 天）设置 available_days，摇优惠场景建议批次时间设置不少于 5 天；② 首批上线前与微信侧核对一次实际生效效期，商户侧按「不含当天」口径计算时需在配置值上减 1 天；③ 验收时通过商品券回调获取次卡整体周期（custom_validity 字段）做校验，并单独验证核销一张后第二张的效期是否与次卡整体周期对齐。
典型反例：认为次卡有效期由微信侧设定；按「不含领取当天」的口径配置天数，导致实际生效天数比活动承诺多 1 天；首批测试券直接配置成一年等过长周期。
见 4015736297-创建商品券、4016439305-商品券（多次优惠）开发指引、4016950448-商品券（单券）常见问题 

 次卡有效期与活动承诺不一致（如承诺 30 天实际 31 天），引发用户争议与活动成本偏差；效期配置过长会拉长核销周期与预算占用，且创建后无法修改，只能重新创建批次。

 兑换券／单品券须如实配置商品券原价，多价格段按实际售卖价填写

 说明：开启兑换价展示（show_as_exchange）时，C 端按「商品原价 − 满减金额」展示优惠金额，商品原价取创建商品券时的 display_info.original_price（单位分，不填写时默认为 0）；单品券未提供商品原价时接口返回 268578476 / INVALID_REQUEST「单品券必须提供商品原价，请补充」。
正确应该怎么做：① 创建商品券时按真实票面价填写 display_info.original_price；② 同一券覆盖多个价格段时按实际售卖价格填写（工单结论：多价格段一般取最高价）；③ 正式上线前用测试券核对 C 端展示的优惠金额与实付差额一致。
典型反例：拼接次卡时为省事统一填写一个测试原价（如 19 元），上线后 C 端展示的优惠金额与实际优惠不符。
见 4015736297-创建商品券、4015736414-查询用户商品券详情、4022248070-商品券（单券）错误码 

 C 端展示的优惠金额与实际优惠不符（如按测试原价算出 3.2 元）；未填原价时接口返回 INVALID_REQUEST「单品券必须提供商品原价，请补充」，券创建失败。

 投放计划的多端核销周期须一致（精确到秒）

 说明：运营规范对可核销时间的要求是多端核销周期一致（精确到秒），即摇优惠侧展示的券有效期须与商家侧（小程序/App）的优惠有效期完全一致。
正确应该怎么做：① 配置商品券批次的券可核销时间时，逐秒比对微信支付侧与商家侧的有效期，保证两端完全一致；② 提交审核前对两端有效期逐项复核。
典型反例：只按商家侧（小程序/App）的优惠有效期配置券，未同步微信支付侧的券可核销时间，两端有效期出现偏差。
见 4017294555-运营规则、4016080826-投放计划配置指引 

 投放活动被驳回，驳回原因为「多端核销周期不一致」，需整改后重新提交审核，活动上线时间延后。

 投放计划名称、商品券名称与券使用说明须按运营规范命名，并与实际权益一致

 说明：运营规范要求「投放计划名称」「商品券名称」「商品券批次-券使用说明」三类命名可参考「品牌 + SKU 系列/品类 + 券类型（如满减券、折扣券）」格式，避免出现混淆用户认知的内容；封顶、限额、限时、使用门槛等限制须在名称或商品券图片中明确标注，次卡券的规则文案还须体现次卡阶梯信息。三类名称与头图、实际权益（天数、适用范围）须保持一致。
正确应该怎么做：① 按「品牌 + 品类/系列 + 券类型」命名，投放计划名称与商品券名称保持一致；② 名称中不写具体权益与最高权益，不写「免费领」「仅限今天」等与实际不符的营销属性表述；③ 存在使用限制（封顶、限时、门槛、0 元券门槛）时在名称或商品券图片中标注，次卡券在规则文案中写清第几次、各次优惠与限制条件；④ 提交审核前对照运营规范自查，被审核打回后按意见修改（活动名称可由运营侧协助修改，商品券名称需商户自行修改）。
典型反例：盲盒类活动名称直接写最高权益；商品券名称写具体权益（如「听歌年卡」）；活动名称写「仅限今天」但活动实际为期多天；名称中的权益天数与头图不一致；次卡规则文案只写单次优惠力度，未体现次卡阶梯与限制条件。
见 4017294555-摇一摇有优惠运营规则、4016080826-投放计划配置指引、4015736297-创建商品券 

 投放计划或商品券审核被驳回（如「活动名称、商品券名称中天数需修改，要与头图一致」），需反复修改重提；次卡配置 check 不通过需返工修改文案，活动无法按排期上线。

 活动说明与券使用说明须多端保持一致

 说明：运营规则要求商家对参与平台优惠活动的商品与活动开展领券、核销全链路体验核验，保障商品及活动信息的准确性与一致性；券的使用限制（封顶、限额、限时、使用门槛）须在投放计划名称、商品券名称或商品券图片中明确标注。活动说明下方「详细信息」部分的文案同样须与商家侧保持一致。
正确应该怎么做：① 核对投放计划名称、商品券名称、商品券批次-券使用说明三类内容与商家侧展示一致；② 一并核对券详情页说明卡片下方「详细信息」区域的文案；③ 存在使用限制时在名称或券图片中标注后再提交审核。
典型反例：只对齐了券说明上方的说明部分，未同步修改下方的详细信息部分即提交审核。
见 4017294555-摇一摇有优惠运营规则、4016080826-品牌经营平台管理投放计划 

 投放计划审核不通过并被要求修改，活动上线时间延后。

 创建投放计划接口默认直接提交审核，需草稿态须显式传 save_as_draft 

 说明：创建投放计划接口的 save_as_draft 默认为否，创建成功后直接提交审核；置为 true 时创建成功但不提交审核，审核状态为「待提审」。调用「更新投放计划」接口修改后同样会重新进入审核流程；投放计划处于审核中时仅支持终止，不允许暂停和修改。
正确应该怎么做：① 自研投放计划管理系统在调用创建接口时，若需运营先编辑确认再提审，显式传 save_as_draft=true；② 按审核时效安排提交时间（工作日 14:00 前提交一般当天完成，之后提交一般 T+1 个工作日完成）；③ 修改已创建计划时预期会再次触发审核，并预留审核窗口。
见 4018381114-创建投放计划、4018381209-更新投放计划、4016080826-投放计划配置指引、4017294555-摇一摇有优惠运营规则 

 运营每次创建或修改都会直接进审核，审核期间无法再暂停或修改，活动排期被打乱并可能错过上线时间。

 投放范围须与实际可履约城市保持一致

 说明：可用门店用于线下核销（到店自提、到店核销）场景，须配置可支持微信支付的门店信息；不涉及线下核销时可不配置可用门店，但投放计划仍须把投放范围限定在实际可履约（有仓储、可配送）的城市，不能按全国通投处理。
正确应该怎么做：① 先按核销方式判断是否需配置可用门店，到店自提或到店核销场景配置可支持微信支付的门店；② 在品牌经营平台创建投放计划时，按实际有仓储、可配送能力的城市勾选投放范围；③ 上线前按运营规则完成领券、核销全链路体验核验。
典型反例：以"券在所有门店通用""接口文档中可用门店非必填"为由不做城市定向，直接全国通投。
见 4017294555-摇一摇有优惠运营规则、4016080826-品牌经营平台管理投放计划、4016081508-摇一摇有优惠开发指引 

 券被投放到无履约能力的城市，用户领券后无法履约、无法使用；集中出现消费者投诉时，平台有权视情况暂停或下线该活动投放。

 限制单用户领取次数须同时配置投放计划与券批次两层限领，且计划层不得超过批次层

 说明：通过投放计划领券时，投放计划维度的限领与券批次维度的限领同时生效，只有既不超过投放计划限领、又不超过批次限领时才能成功领券；投放计划层提供单用户领取上限（user_limit）与单日领取上限（daily_limit），批次层「每个用户领取次数上限」max_count_per_user 最多 100 次；同一批次被多个投放计划配置时，批次维度的限领数量由多个计划共用。
正确应该怎么做：① 创建投放计划时按营销诉求显式配置 user_limit 与 daily_limit，并使其不大于券批次的单用户限领与每日限领；② 希望一个用户只能领取一次时，将批次 stock_send_rule.max_count_per_user 设为 1（运营侧创建券码时同步设置 limit），并同时核对投放计划侧限领；③ 一个批次建议只配置到一个投放计划，避免批次限领被多计划分摊；④ 需要避免同一用户在首张券有效期内再领到不同面额券时，以投放计划层的单用户限领为准配置。
典型反例：仅在前端活动页做「每人限领一次」的展示限制，批次 max_count_per_user 仍保持较大的默认值；只在券批次层配置了单用户限领，投放计划层未配置 user_limit。
见 4016080826-投放计划配置指引、4018381114-创建投放计划、4015736297-创建商品券、4017418651-摇一摇有优惠常见问题、4023120617-错误码 

 创建投放计划返回 268585138「活动单用户领取上限需小于券批次单用户领取上限」、268588725「投放计划每日限领不应大于批次每日限领」，计划创建失败；或限领未生效，同一用户反复领取次卡券，活动库存被少数用户消耗、其他用户无券可领，活动预算超出预期。

 单用户限领按 uin 判定，核对领取量须按 uin/openid 维度

 说明：投放计划的 user_limit 为单用户维度的限领数量，限领按用户账号（手机号转 uin）维度判定，不是按手机号维度判定。
正确应该怎么做：① 用回调返回的 openid／unionid（uin）维度统计与核对领取量；② 排查「同一手机号超过限领」时，先确认该手机号是否已映射到 uin。
见 4018381114-创建投放计划、4015755761-商品券回调通知 

 按手机号维度统计会出现同一手机号领取量远超限领配置的情形，被误判为超发或被薅羊毛。

 人群包上传后须回查状态确认生效再投放，处理中不得重复提交

 说明：人群包走的是离线扩充链路，与联合投放配置「接口应答返回即生效、无异步同步窗口、无回调通知」不同，人群包上传接口返回成功仅表示提交已被受理，需离线处理完成后状态与人数才会更新；处理未完成前后台会显示「人群包为空」，此时重复提交会返回「上传失败，人群包正在处理中」。
正确应该怎么做：① 调用人群包上传接口后，到品牌后台查看该人群包的状态与人数；② 确认状态为「生效中」且人数已更新后，再把人群包关联到投放计划并启动投放；③ 状态长期停留在「处理中」时不要重复上传，离线处理完成后状态与人数会自动更新；④ 长时间未更新时，向微信侧提供包名（userPackageId）与 uploadId 联系运营/技术支持，由平台侧重跑离线流程。
典型反例：上传接口返回成功即认为人群包已可用，直接把该人群包挂到正在投放的计划上。
见 4024833914-联合投放产品介绍、4016080826-投放计划配置指引 

 品牌后台显示「人群包为空」，再次提交返回「上传失败，人群包正在处理中」；正在应用该人群包的投放计划因人群包无数据而发不出券，活动投放中断。

 人群包扩充须扩到本品牌（brand_id）名下的人群包，不可跨品牌混用

 说明：人群包与品牌（brand_id）绑定，做人群包扩充时必须扩到本品牌已有的人群包上，不同品牌的人群包不能混用。
正确应该怎么做：① 对接人群包扩充能力前，确认本品牌下已有可用人群包；② 扩充请求指向本品牌（brand_id）名下的人群包；③ 多品牌并行投放时按品牌分别申请与扩充，不要把 A 品牌的人群扩到 B 品牌。
典型反例：沿用另一品牌（如 15243）已有人群包去扩充本品牌（如 5822）的投放人群。

 扩充任务长期处于"执行中"或报权限异常，人群不生效，定向投放无法触达目标用户。

 人群包合并成功到扩充成功为异步过程，需按小时级延迟重试等待

 说明：人群包合并完成后，扩充为异步任务，从合并成功到扩充成功可能存在数小时延迟，期间返回的执行中/未完成提示属正常现象。
正确应该怎么做：① 调用扩充后按任务状态轮询（如每 5 分钟一次）等待结果；② 以最终扩充成功状态为准，不要把中间态提示当作报错上报；③ 若除该提示外还伴随其他异常报错，再按具体报错另行排查。
典型反例：合并成功后短时间内未见扩充结果即判定接口故障、反复提单或重复提交人群包。 

 误判为故障而重复提交人群包、延误投放排期；实际无其他报错时本无需处理。

 定向发券所需的用户身份信息须由商户侧识别并提供，微信侧不提供

 说明：用户的手机号、位置、新老客身份等信息不由微信侧提供，需由商户侧自行识别后提供给微信侧做用户定位；跨多品牌/多小程序判断「新客」同样需商户侧自行完成身份关联。同一微信用户在同一个微信开放平台账号下的 unionid 唯一且不变，可用于关联同一用户在不同小程序的身份。
正确应该怎么做：① 由商户侧完成新老客、城市、手机号等用户属性的识别；② 将各小程序绑定到同一个微信开放平台账号，用 unionid 把多品牌/多小程序的用户身份统一映射到目标小程序的 openid；③ 将识别结果以人群包/联合投放配置的方式提供给微信侧用于定向；④ 按摇优惠开发指引的交互流程联调，不要设计「发券前向微信侧查询用户身份」的链路。
典型反例：把「发券前调用微信接口获取用户手机号、位置、新老客身份」写进技术方案；期望由微信侧自动识别跨品牌新客。
见 4016081508-摇一摇有优惠开发指引、4016080147-权限申请、4015755761-商品券回调通知、UnionID机制说明 

 定向人群无法配置，新老客/分城市差异化发券方案无法落地，会员同步开发排期被卡住，方案评审后需返工重做。

 存量会员须先导入会员卡，再由运营创建人群包并在创建活动时勾选

 说明：摇优惠人群包带新老会员校验，须先通过「根据OPENID导入用户会员卡」接口把存量会员 openid 导入到会员，曝光时才会被校验为老客并发券；该接口要求用户 OpenID 对应的 AppID 与会员卡所属的品牌号绑定。
正确应该怎么做：① 调用「根据OPENID导入用户会员卡」接口（/brand/card-member/user-cards/import-by-openid）把存量会员 openid 导入会员卡模板；② 联系微信支付运营创建老会员人群包；③ 创建投放活动时勾选该老会员人群包，对应用户即可获得活动曝光。
见 4015582744-根据OPENID导入用户会员卡 

 同步过来的存量会员不会进入曝光池，曝光时不判定为老客，活动无法触达这批用户。

 联合投放须通过在线接口分批写入，单次 200~2000 个用户，不支持离线文件

 说明：联合投放场景下为指定用户配置「可参与的投放计划」，目前仅支持通过 BatchSetUserJointDeliveryConfig 在线分批写入，单次 200~2000 个用户；暂不支持以离线文件形式一次性上传并完成配置，单次传入超过上限会报错。
正确应该怎么做：① 按单次 200~2000 个用户分批调用接口循环写入；② 千万／亿级名单按批次拆分后循环调用，不要改为一次性提交；③ 如需一次性导入大规模用户名单，改走人群包＋定向投放方式（见下文「准入限制与特殊 QA」）。
典型反例：计划通过一次性上传离线文件完成亿级名单的联合投放配置。
见 微信支付品牌经营-联合投放接口文档 4017348695、4023120617-摇一摇有优惠错误码 

 单次传入用户数超过 2000 时接口报错，联合投放配置无法写入，指定用户无法参与该投放计划。

 收到领券回调后须调用「确认发放用户商品券」接口确认发券，券才可核销

 说明：用户领券后微信支付会下发商品券回调通知（含 openid、unionid、coupon_code），此时用户券状态为「待确认发券」（CONFIRMING）；须由品牌方在自有系统为用户发券后调用「确认发放用户商品券」接口确认，券才会流转为待生效或已生效并可被核销。不论券由摇优惠等微信营销渠道发放，还是品牌方调用发券接口主动发放，均需确认。
正确应该怎么做：① 通过「设置商品券事件通知地址」接口配置品牌维度的回调地址；② 接收回调时先做签名验证与幂等处理（同一通知可能多次发送），并在品牌侧系统为用户发放对应的券；③ 调用「确认发放用户商品券」接口，传入用户 openid 与 coupon_code 完成确认；④ 确认发放完成后再调用「核销用户商品券」接口执行核销。
典型反例：仅接收并应答领券回调、在品牌侧完成建券，但未调用确认发券接口，用户券长期停留在待确认状态。
见 4015755761-商品券回调通知、4015736403-确认发放用户商品券、4016060894-商品券（单券）开发指引、4015736433-核销用户商品券 

 用户券停留在「待确认发券」（CONFIRMING）状态未生效，商家侧查不到该券、支付页不展示也不抵扣；核销用户商品券接口因「已发券成功且当前可用」的前置条件不满足而核销失败，用户投诉后只能人工补券补偿。 

 领券回调须按 openid、unionid 必填解析并落库，券记录查询须凭用户标识而非券 code

 说明：微信侧下发的商品券回调通知中 openid（领券用户在 AppID 下的唯一标识）与 unionid（领券用户在 AppID 所属微信开放平台账号下的唯一用户标识）均为必返回字段；查询用户商品券类接口以用户维度发起，核对某用户的发券/领券记录时须提供 openid/unionid 或手机号，仅有券 code 无法定位到具体用户的券记录。一个微信账号只有一个 unionid，同一微信账号在不同 appid 下会有不同的 openid，不同 appid + openid 指向同一 unionid 即为同一用户。
正确应该怎么做：① 回调接收端把 openid 与 unionid 作为必填字段解析并落库，不做空值兜底跳过，并与券 code 一并留存；② 跨 appid 判断是否同一用户领券时以 unionid 为准，同一 appid 内以 openid 为准；③ 客诉排查与对账时提供用户标识（unionid 或手机号）查询券记录，用户拒绝授权手机号时用 openid/unionid 兜底。
典型反例：认为通知中 openid / unionid 可能缺失，券记录仅按手机号或商家侧账号建索引；只在订单/券表中保存券 code，用户投诉「券未到账」时拿不出可查询的用户标识。
见 4015755761-商品券回调通知、4016950448-商品券（单券）常见问题、4015736414-查询用户商品券详情、4015736420-指定券状态查询用户商品券列表、UnionID机制说明 

 券记录与用户账号无法准确匹配，跨 appid 场景下同一用户被识别为多个用户，出现重复发券或核销时找不到券；客诉工单因缺少用户标识无法查询发券记录，「券未到账」「券被占用」类投诉无法闭环。

 领券回调与用户券查询须统一使用 notify_appid 对应的 openid

 说明：商品券回调通知中的 appid 取批次配置的 notify_config.notify_appid，该 AppID 用于券事件通知时计算用户的 OpenID，且需要与品牌存在绑定关系；回调同时返回 openid 与 unionid，查询用户券的接口以 openid 作为路径参数。
正确应该怎么做：① 添加商品券批次时填写与品牌存在绑定关系的 notify_appid（支持小程序、服务号、公众号、APP 类型）；② 接收回调时同时持久化 openid 与 unionid，用 unionid 打通同一开放平台账号下公众号与小程序各自的 openid；③ 查询、核销用户券时使用 notify_appid 对应的 openid，使领券与查询链路的 appid 保持一致。
典型反例：批次的 notify 配的是公众号 AppID，后续查询与核销却走同主体小程序的 openid，导致领券记录查不到、领券数据无法维护。
见 4015755761-商品券回调通知、4015736342-添加商品券批次、4015736420-指定券状态查询用户商品券列表、UnionID机制说明 

 查询不到用户的领券记录，券状态无法核对，用户领券数据无法长期维护，客诉排查时无法定位。

 主动调用发券接口发券时须自行引导用户查看，勿依赖微信消息通知

 说明：领券后摇优惠会在消息列表中的「微信支付」账号内向用户推送券的过期、核销、退券等消息，用户可在摇优惠「我的-待使用优惠-全部优惠」查看已领取的券；通过发券接口主动发放的券不会向用户下发领取消息。
正确应该怎么做：① 让用户在前端有明确的领取动作，而不是在用户无感知的情况下直接发放；② 在商家自有渠道引导用户到摇优惠查看已发券；③ 结合券到期前的过期提醒做二次触达。
见 4015782176-摇一摇有优惠产品介绍、4015736390-向用户发放商品券 

 用户不知道券发到了哪里，券的领取率与核销率低下，营销投入无法转化为核销。

 领券手机号授权为一次性持久化授权，已授权用户不再重复弹出授权

 说明：用户授权领券手机号后，后续领券不再重复弹出授权页，回调中仍会返回 phone_number；回调 phone_number 非空即表示该用户已被灰度到手机号发券。
正确应该怎么做：① 服务端以回调中的 phone_number 判断用户是否提供了手机号，不以"领取页是否出现授权弹窗"作为判断依据；② 验收或复现授权流程时，在摇优惠「右上角三个点 → 设置 → 领券账号设置」中关闭「允许指定商家领券至手机号」，重新领券即可再次触发授权；③ 按手机号发券时遵循优先级：微信回传的 openid-手机号与商户侧一致才发券，不一致则挂起资格待用户绑定准确手机号后再下发，回调未带手机号时兜底用 openid 发券。
典型反例：以"领取页没有出现授权手机号的操作"判定手机号能力未生效，进而认为回调手机号不可用。
见 4015755761-商品券回调通知、4016950448-商品券（单券）常见问题 

 误判手机号能力未生效而重复提单排查；商户侧"手机号不一致挂起"的发券逻辑无法验证，手机号发券链路无法验收。

 券可用周期内须复用同一套发券入参获取 token，不要每次重新生成

 说明：领券组件的语义是发券，每次生成新 token 即视为一次新的发券；使用相同参数获取的 token 拉起组件时，组件按用户当前状态展示（用户已领取过时返回已领取状态并可查看使用进度）。获取 token 的流程不做幂等处理，每次调用都会返回不同的 token，token 有效期为 5 分钟，过期后需重新调用接口获取。
正确应该怎么做：① 端内保存的是发券入参而非 token 本身，并保持公众账号 ID（appid）、发券请求单号（send_request_no）、attach 等参数与首次发券完全一致；② send_request_no 按「用户＋批次」维度固定，不要每次用新的 uuid；③ 需要再次展示次卡进展时，用同一套入参重新调用「向用户预发放商品券」接口取 token 后调起组件，可将「首次点击＝发券、再次点击＝看进度」作为固定资源位逻辑；④ token 超过 5 分钟或已失效时重新调用接口获取，不要长期缓存后复用过期 token。
典型反例：每次进入页面都用新的 send_request_no（如 uuid）重新调用预发券接口；只缓存 token 而不保存发券入参，token 过期后无法用原参数复原；已领券用户每次以不同参数重新预发券并调起组件，导致提示已达领取上限且看不到次卡进度。
见 4016416620-向用户预发放商品券、4016418207-调起小程序发券组件、4016416237-小程序发券组件开发指引、4016950448-商品券（单券）常见问题 

 同一用户被重复发券；在已限制每用户领取次数的批次上，再次调起组件时提示「达到领取上限」，无法查看已领次卡的使用进度，产生客诉；复用过期 token 导致组件打开失败。

 券不可用（过期／失效／全部核销完）时须用新的发券单号重新获取 token

 说明：用户券失效、已过期、所有轮次已核销完成均属于「券不可用」，此时平台会拦截组件调用并返回错误码 268603238；接口侧对应错误码 ALREADY_EXISTS（HTTP 400），提示「该券已不可用，如需重新发券，请使用新的发券单号」。
正确应该怎么做：① 调用预发券接口与调起组件时捕获该错误码；② 判定为券不可用时，改用新的发券请求单号（send_request_no）重新调用预发券接口获取新 token，拉起新一轮领券组件；③ 由商家侧系统按券状态自动完成轮换，或按固定周期更换货盘批次。
典型反例：券已过期仍复用原发券单号重试；或对返回状态做静默处理后用户点击入口无任何反馈。
见 4016416620-向用户预发放商品券、4016416237-小程序发券组件开发指引 

 组件调用被平台拦截并返回 268603238「该券已不可用，如需重新发券，请使用新的发券单号」，用户点击入口无法调起领券组件，新一轮次卡无法发放。

 次卡「去使用」须由商家小程序按组件返回的 path 自行跳转

 说明：用户领取次卡后点击「去使用」，领券组件会关闭半屏弹层并回调返回后台配置的单品跳转路径，是否跳转、跳转到哪里由商家小程序自行完成；非全场券的核销跳转路径需指向可用券商品列表页或商品详情页。
正确应该怎么做：① 在后台为次卡单品配置正确的商品 path（商品详情页或可用券商品列表页）；② 小程序在组件回调中接收该 path，自行完成页面跳转并引导用户进入下单页；③ 端内未实现跳转逻辑时需补齐，不要依赖组件自动跳转。
典型反例：只配置后台商品 path，端内未按回调 path 实现跳转逻辑。
见 4016416237-小程序发券组件开发指引、4017294555-摇一摇有优惠运营规则 

 用户点击「去使用」后停留在原页面、无法进入商品详情页，找不到可用券商品，次卡核销率下降并引发用户咨询。

 从微信支付／卡包跳转商家小程序时须自行识别用户并兼容参数缺失

 说明：微信侧仅按商户自行配置的跳转链接跳转，不额外携带参数；从微信卡包点击卡券「立即使用」的跳转不会携带核销组件参数，只有接入核销组件且从摇一摇会场「去小程序使用」跳转才会携带核销组件的参数，商户侧需要做兼容处理。
正确应该怎么做：① 不要假设跳转链接会带回领券用户标识，在小程序内通过 openid 自行判断领券用户与当前进入小程序的用户是否为同一人；② 按核销组件开发指引接入组件并判断用户登录账号状态；③ 对未携带核销组件参数的入口（如卡包「立即使用」）做兜底处理。
典型反例：直接依赖跳转 URL 上带的参数识别用户，未做参数缺失兜底。
见 4016081508-摇一摇有优惠开发指引、4016105616-小程序核销组件开发指引 

 无法识别领券用户与进入小程序的用户是否为同一人，出现「用户领了券但在商家小程序里找不到券」的客诉，券核销率下降。

 核销商品券时必须传入 associated_order_info 或 associated_pay_score_order_info 之一

 说明：核销用户商品券时，订单信息必须且只能传入 associated_order_info（微信支付订单）与 associated_pay_score_order_info（微信支付分订单）之一；该要求与券类型、券配置及商户品牌无关，0 元兑换券同样需要传入。
正确应该怎么做：① 按券实际对应的交易类型选择其一：有微信支付订单时传 associated_order_info，并在其中至少传 transaction_id 与 out_trade_no 之一（二者同时传入须指向同一笔单）；② 0 元兑换券等无微信支付订单的场景，传 associated_order_info.out_trade_no（商户侧单号）并同时传下单商户号 mchid，服务商模式下单还需传 sub_mchid，直连模式不传；③ 服务端统一组装该参数，不要参照个别早期批次未做校验的历史表现省略。
典型反例：以"其他品牌商户不传订单信息也能核销成功"为依据，在新批次券上直接省略订单信息字段。
见 4015736433-核销用户商品券 

 核销接口返回 400 PARAM_ERROR，提示「至少传入associated_order_info或associated_pay_score_order_info之一」，券无法核销，用户已领权益无法完成履约。 

 摇优惠卡包不展示券码，核销链路不要依赖用户出示 coupon_code 

 说明：创建商品券时 coupon_display_info.code_display_mode 决定用户商品券 Code 在卡包中的展示形态，可选不展示 Code（INVISIBLE）、条形码（BARCODE）、二维码（QRCODE）三种；在摇优惠场景下券码不展示，用户无法通过任何途径获取 coupon_code。
正确应该怎么做：① 核销走「核销用户商品券」接口或小程序核销组件，以 openid 查询用户券后核销；② 线下场景可把 coupon_usage_method_list 配为 PAYMENT_CODE（微信支付付款码核销），由商家扫付款码获取用户 openid 后查询并核销用户券，再发起下单；③ 核销流程不要设计成需要用户在前端报券码。
典型反例：把券的展示模式切成 QRCODE，指望用户在摇优惠卡包页面看到券码并出示给门店核销。
见 4015736297-创建商品券、4015736342-添加商品券批次 

 用户在摇优惠内拿不到券码，报码核销链路走不通，券无法核销并引发用户客诉。

 摇优惠券的核销与发奖须以领取用户的微信账号为准，不支持跨账号体系兑换

 说明：摇优惠发放的券与领取用户的微信账号绑定，核销与奖励发放都落在该微信账号下；若品牌业务同时存在其他账号体系（如 QQ 登录账号），微信领取的券只能在微信账号下兑换，不能兑换到其他账号体系的账号。
正确应该怎么做：① 核销与发奖接口以回调通知中的 openid / unionid 所对应的微信账号为准回写奖励；② 核查「奖励未到账」类客诉时，先核对用户进线手机号与领取券的微信号是否一致，再按券批次号与券 code 查核销状态；③ 在活动页面与用券说明中明示奖励发放至领取所用的微信账号。
典型反例：用户提供的主用账号为其他账号体系（如 QQ 登录账号），品牌按该账号查询奖励而得出「未到账」结论。
见 4015755761-商品券回调通知、4016950448-商品券（单券）常见问题、UnionID机制说明 

 后台显示券已核销、奖励已发放，但用户在自己常用的其他账号下查不到奖励，产生「奖励未到账」客诉并增加人工核查成本。

 发奖逻辑不得假设用户已访问或登录过商家小程序

 说明：用户在「摇一摇有优惠」会场摇到券后，微信支付直接把商品券发放给用户并下发发券回调通知；用户从未打开过商家小程序也可以领到券，并在摇优惠会场看到该券。
正确应该怎么做：① 按商品券开发指引接入必接接口，以微信支付下发的发券回调通知作为品牌侧发奖依据，不把"用户是否在小程序有过访问或登录"作为发奖前置判断；② 领券后的核销环节接入核销组件，用于判断用户在商家小程序的登录账号状态并定位适用商品；③ 对从微信卡包「立即使用」跳转（不携带核销组件参数）的路径做兼容处理。
典型反例：把"用户必须先访问或登录商家小程序"作为建券或发奖的前置条件，导致从未打开小程序的领券用户在商家侧查不到券。
见 4016081508-摇一摇有优惠开发指引、4016060894-商品券开发指引、4015736403-确认发放用户商品券、4016105616-核销组件开发指引 

 从未打开过小程序的领券用户在商家侧查不到券、券无法使用，引发"活动虚假"类客诉；微信侧发券记录与品牌侧发奖记录不一致，对账与补发成本上升。

 券批次库存发完或批次失效后须补充库存，并等待投放计划重新审核通过

 说明：投放计划活动时间未结束，但配置的商品券批次已失效或批次库存已发完时，投放计划不会终止，而是自动进入「已暂停」状态，客户端推荐券时会因没有可投放的券而过滤掉该计划；扩充批次库存后会自动进入审核流程，审核通过后重新进入「投放中」继续发券。主动调用「暂停投放计划」接口暂停的计划不会因库存变动自动进审核，须调用「恢复投放计划」接口触发审核。
正确应该怎么做：① 调用「修改商品券批次发放预算」接口扩充该批次库存（每次调用只能调整一个维度的预算，多维度需多次调用），也可改用其他有效批次；② 补充库存后确认投放计划已重新进入审核并通过；③ 若为主动暂停的计划，补充库存后须另行调用「恢复投放计划」接口才触发审核。
典型反例：券批次库存耗尽后，仅在品牌经营平台把券总数量从 20 万改成 200 万，未调用「修改商品券批次发放预算」接口扩充该批次可用库存，投放计划仍显示「已暂停」。
见 4017418651-摇一摇有优惠常见问题、4015736398-修改商品券批次发放预算、4018381172-恢复投放计划、4016080826-投放计划配置指引 

 投放计划停留在「已暂停」，C 端不再曝光该活动、用户领不到券，活动静默停投且商家不易察觉。

 预存 Code 模式的批次补充库存后须同时补充券 Code

 说明：coupon_code_mode 为 UPLOAD（品牌方预上传 Code）时，发券由微信支付从已上传的 Code 中随机选取，当预存 Code 不足时可能影响发券，品牌应及时补充。
正确应该怎么做：① 调用「修改商品券批次发放预算」接口扩充库存的同时，调用「预上传券CODE」接口补齐 Code；② 通过批次返回的 coupon_code_count_info.available_count（当前可用 Code 数）监控余量，低于发券计划时提前补。
见 4015736297-创建商品券、4015736400-预上传券CODE 

 批次库存额度已扩充但可用券 Code 不足，用户仍领不到券或发券失败，补库存的动作不产生实际发放量。

 移除用户券接口按"需保留的券"覆盖式设置，须先查询用户持券

 说明：该接口的语义是设置用户保留哪些券，而不是传入"要删除的券"；传入的集合会覆盖用户原有的持券集合。
正确应该怎么做：① 先调用查询接口获取用户当前持有的券（如 a、b、c）；② 将需要保留的券（如 a、b）作为集合传入移除/设置接口，未包含在集合中的券（c）即被移除；③ 变更前先查询、变更后复核用户持券列表。
典型反例：直接把"要移除的券 c"作为唯一入参调用，导致用户原有的其他券被整体覆盖清空。
见 4017348695。 

 用户仍在有效期内的券被误移除，用户资产损失并引发客诉，需要人工补发。

 验收领券流程须在投放计划「体验设置」配置体验人员并扫预览二维码

 说明：投放计划创建完成后，需在品牌经营平台「摇优惠-投放计划-投放计划管理-体验设置」配置体验人员微信号（至多 10 个），再用已配置体验人员的微信扫描预览生成的体验二维码领券；未配置体验人员的微信扫码会提示没有体验权限。
正确应该怎么做：① 在经营平台体验设置中配置测试微信号；② 点击预览按钮生成体验二维码，用该微信号扫码；③ 领取后确认券进入测试人员微信账户，再验证领券回调、核销、退券链路；④ 测试场景会展示两个同样的领券页面，领取第一张后接着领第二张会提示"领取失败，请稍后再试"，需重新扫码进入新的测试领券页面；若提示领取失败，还需检查批次库存是否充足、预上传 code 模式是否已补充 code。
典型反例：完成微信号加白后直接扫其他来源的二维码（或历史活动码）验收，未走投放计划预览二维码。
见 4016080826-投放计划配置指引、4016950448-商品券（单券）常见问题 

 扫码提示"没有体验权限"或"领取失败，请稍后再试"，无法完成摇一摇领券主流程验收，误判为能力未开通。

 申请配置测试活动前，券批次须满足结束时间与库存门槛

 说明：请微信侧在测试环境配置测试活动时，券批次需满足批次结束时间在 15 天以上、库存在 10000 以上，否则无法创建测试活动；领取环节提示参数异常多因该账号未在测试环境加白，加白仅用于测试环境数据查看，领券成功即视为验证通过。
正确应该怎么做：① 提前按上述门槛创建专用测试批次（结束时间 15 天以上、库存 10000 以上，该批次不会投放到公域）；② 提交批次号请微信侧配置测试活动；③ 用已加白账号扫码验证领券主流程，以领券成功为准，不必强求在测试环境查看数据。
典型反例：沿用临近过期、或库存仅几百张的正式批次去申请测试活动。 

 测试活动创建失败（提示"时间已过使用时间""库存不足1W"），摇一摇领券主流程无法在测试环境联调。

 定向投放与人群包能力须联系微信支付运营开通，人群包由运营侧创建、商户侧按接口传入标识

 说明：品牌经营平台创建投放计划时投放用户默认仅支持「智能通投」（基于用户在微信支付的消费偏好投放），投放计划页面默认没有定向投放模块；定向投放（TARGETED）与人群包能力须联系微信支付运营开通后方可使用，定向投放模式必须传 plan_label，智能投放模式不允许传 plan_label。人群包由微信支付运营侧开通权限并在后台创建，商户侧通过接口传入人群包标识 user_package_id 使用。
正确应该怎么做：① 先联系微信支付运营开通人群包上传/定向投放能力，并提供商家名称与品牌 ID；② 由运营侧在后台创建/配置该品牌下的人群包并给出人群包 ID；③ 商户侧在投放或发券接口中传入该 user_package_id，不自行构造人群包；④ 创建投放计划时按定向模式传 plan_label；⑤ 提交人群包文件时把人群包名称控制在字符数限制内，超限需缩短后重新上传；⑥ 亿级名单等大规模一次性导入场景改走人群包＋定向投放，不要指望联合投放以离线文件导入。
典型反例：未申请权限即按接口文档直接传自建人群包标识调用定向投放接口；把「上传人群包文件」当作商户自行创建人群包；使用 TARGETED 模式但未传 plan_label。
见 4016080826-投放计划配置指引、4023120617-摇一摇有优惠错误码、4024287065-定向投放 

 只能全量智能通投，无法按自有会员/指定人群定向发券；调用接口返回 NO_AUTH（商户无权限）、268593052 / PARAM_ERROR「定向投放模式必须传 plan_label」，定向投放无法生效，活动只能降级为通投或等待权限开通后延期上线。

 投放计划须预留审核时间，审核通过不等于已上线

 说明：投放计划创建后进入审核流程，官方给出的审核时效为工作日 14:00 前提交一般当天审核完成、14:00 后提交一般 T+1 个工作日完成（经营平台页面创建一般为 2 个工作日内完成审核）；审核通过并不等于已对 C 端曝光，还需由运营侧人工安排批量上线。
正确应该怎么做：① 按期望上线时间倒排，至少预留 1~2 个工作日审核时间，尽量在工作日 14:00 前提交；② 需当天上线的活动按运营给出的上线时点提交（运营给出的上线时点为：当天 17:00 前提交审核且无问题的活动当天可上线，超过 17:00 提交的需次日上线）；③ 审核通过后与运营确认批量上线时间，并以投放计划状态变为「投放中」作为对 C 端开始曝光的判断依据；④ 审核意见为名称类问题时，活动名称可由运营侧协助修改，商品券名称需商户自行修改后重新提交。
典型反例：看到审核通过即认为活动已上线，未与运营确认上线批次就对外宣传。
见 4017294555-运营规则、4016080826-投放计划配置指引 

 活动无法在预期时间上线、营销排期推迟；活动实际未上线但商户已按上线做宣传与库存准备，用户端看不到活动，产生「虚假宣传」类客诉。

 替换人群包接口返回「上传成功」不代表人群已替换，有效用户为 0 时静默不覆盖

 说明：替换人群包时会先做手机号 MD5 到 uin 的映射并离线统计有效用户；有效用户为 0 时按接口约定视为无效替换，静默不覆盖，包内人数保持不变，接口仍返回「上传成功」且不回传映射失败。
正确应该怎么做：① 上传后主动核对人群包人数是否变化，不要只看接口返回；② 上传文件中保留足够样本，避免整包仅 1 条且该条手机号无法映射到 uin；③ 通过运营／产品侧确认本次映射成功的有效人数与生效时间。
典型反例：把一个 6000 万+ 的排除人群包替换成 1 人，接口提示「上传成功」，实际人群包人数仍是 6000 万+。

 排除人群包持续生效，定投发放规模大幅下降，且商家无法从接口返回值感知替换失败。

 免费兑换类活动在审核规则调整期暂不受理新增，付费卡券不受此限制

 说明：微信侧运营通知，摇优惠免费兑换活动（含免费盲盒）的审核规则重新制定期间暂不接受新增，该要求对所有品牌一视同仁且不通融，需等规则确定后再新增；付费卡券、付费兑换活动不受该限制，可正常提交。
正确应该怎么做：① 提审免费兑换类投放计划前，先与微信侧运营同学确认该类活动当前是否恢复受理；② 暂停期内改用高优惠力度的付费兑换活动排期；③ 付费卡券的投放计划按正常流程登记并提审。
典型反例：在暂停期内继续按原节奏批量提审免费兑换或免费盲盒计划，并期望个案通融。
见 4016080826-品牌经营平台管理投放计划、4016081508-摇一摇有优惠开发指引 

 免费兑换、免费盲盒类投放计划在暂停期内提审不被受理，活动排期与上线时间整体延后。

 人群包接口传入的人群包不能与联合投放配置关联到同一投放计划

 说明：可与联合投放一起配置的是平台标签里的人群配置；通过人群包接口传入的数据不能与联合投放一起配置（人群包接口数据可与平台标签里的人群配置同时关联到同一投放计划）。
正确应该怎么做：① 需要人群包与联合投放并存时，人群侧使用平台标签里的人群配置；② 人群包接口传入的数据单独关联投放计划，不与联合投放配置混用。

 按「接口人群包＋联合投放」的组合去关联投放计划，配置无法按预期生效，指定人群的投放计划无法上线。

 人群包与联合投放同时命中时取并集，黑名单优先级最高

 说明：同一投放计划同时关联人群包与联合投放时，两者是并存关系、取并集，不存在优先级；命中黑名单的用户优先级最高，只要配置了黑名单即不可见。
正确应该怎么做：① 需要排除用户时统一通过黑名单配置，不要指望用某一侧的「排除」覆盖另一侧的「准入」；② 预估投放覆盖量时按并集口径测算。

 投放人群与预期不符：被黑名单排除的用户仍被计入预期曝光，或误判「准入」可覆盖「排除」导致实际曝光人群偏差。

 次卡领券组件要求微信客户端 8.0.30 及以上，鸿蒙系统暂不支持

 说明：次卡组件需要微信 8.0.30 及以上版本，鸿蒙系统当前微信版本（8.0.22）不满足，平台会返回 toast 提示；iOS／安卓低版本微信会提示用户更新至最新版本。
正确应该怎么做：① 端内对组件调起失败状态做兜底与提示；② 鸿蒙系统上不要把次卡作为首页 icon 等主路径的唯一形态，需做降级处理。

 鸿蒙系统用户无法展示与调起次卡组件，只能看到平台返回的 toast 提示，次卡入口与首页 icon 不可用。