文档地址：「请求分账（直连）」、「请求分账（服务商）」 Q1：调用请求分账接口返回”非分账订单不支持分账“是什么原因？ A1：请按照以下几点检查： 微信订单号填写错误，请检查确认统一下单时未上传分账标识（profit_sharing=Y）的订单，是不支持分账的 Q2：调用请求分账接口返回”分账金额不足“是什么原因？ A2：请按照以下几点检查： 该订单已全额退款，没有资金可以分账在微信支付中，实际收款之后微信支付会收取一定的结算手续费，在减去手续费后剩余的钱才能分账，详情可参考订单结算手续费说明该订单已解冻，已无分账资金（普通商户分账订单默认冻结期是30天; 电商分账订单默认冻结期是180天）超过订单剩余可分账金额或者该订单已无可分账金额，请检查确认（可调用查询订单待分账金额API确认剩余可分账金额） Q3：调用请求分账接口返回”分账接收方关系不存在，请检查参数中每个接收方的关系“是什么原因？ A3：未添加分账接收方，分账接收方在分账之前需要调用“添加分账接收方接口”添加，请添加接收方后再调用请求分账接口。 Q4：调用请求分账接口返回“分账金额超出最大分账比例”是什么原因？ A4：请检查分账的金额是否超出在商户平台设置的允许分账的最大比例，设置路径如下： 普通直连商户设置分账比例路径：登陆商户平台-产品中心-分账-分账管理比例普通服务商商户设置分账比例路径：需要特约商户可以登录商户平台-产品中心-授权的产品-分账授权中进行设置比例。电商收付通商户设置分账比例路径：登陆服务商商户平台-产品中心-我的工具箱-电商收付通-供应链分账设置里设置连锁品牌分账商户设置分账比例路径：登陆服务商平台-产品中心-合作工具箱-连锁品牌工具箱-品牌专区-品牌交易-品牌供应链分账-供应链分账管理设置 Q5：调用请求分账接口返回”无分账权限“是什么原因？ A5：请按照以下几点排查： 1、未开通分账权限，请开通后再调用分账接口，可参考开通指引 2、请求参数错误，服务商用了普通商户的开发文档提交参数，检查确认 服务商模式请求分账文档 普通商户分账文档 Q6：分账调用“添加分账接收方接口”返回：微信用户姓名与实名不一致 A6：请求中传了字段“个人姓名name”，该字段传了之后会校验用户实名是否正确，请填写正确的用户实名（查看用户实名认证路径：微信-我-服务-右上角三点-实名认证-姓名） Q7：分账调用“请求单次分账接口”返回：分账接收方列表格式错误 A7：receivers中的参数amount类型错误，amount类型是int，请检查确认 Q8：分账接收方类型包括哪些？ A8：有以下几个类型： MERCHANT_ID：商户ID PERSONAL_OPENID：个人openid（由父商户APPID转换得到）PERSONAL_SUB_OPENID: 个人sub_openid（由子商户APPID转换得到） Q9：分账调用“请求单次分账接口”，为什么不返回分账结果 A9：分账是异步的，需要调用“查询分账结果”接口查询确认 Q10：分账调用“请求分账接口”返回：订单处理中，请稍后重试 A10：请按照以下几点检查： 请在订单支付成功1分钟后再调用分账接口未结算的订单，请在结算后再调用分账接口请求分账。查看结算周期路径：超级管理员使用电脑登录商户平台（pay.weixin.qq.com），通过【账户中心】->【商户信息】->【结算信息】进行查看老资金流商户的订单，不支持分账（旧资金流流水介绍、新资金流流水介绍）商户开通了收支分离但手续费账户余额不足（手续费账户最低余额要求是100元以上，在充值手续费账户1小时后，订单会正常结算，即可正常调用分账接口） Q11：分账调用“请求分账接口”返回：分账接收方与原请求不一致 A11：商户分账单号填写错误，调用“请求分账接口”多次分账，要生成新的“商户分账单号”，不能使用已经分过账的商户分账单号 Q12：分账调用“请求单次分账接口” A12：请按照以下几点检查： 签名类型错误，分账接口签名类型目前只支持HMAC-SHA256普通商户的分账订单，请使用普通商户分账接口，不能使用服务商分账接口系统超时，请使用原参数尝试再次掉调用API Q13：调用分账接口是否有额外的手续费 A13：没有，商户的交易订单，平台会正常的收取结算手续费。商户使用分账功能没有额外的费用 Q14：分账调用“请求分账接口”返回：分账接收商户全称不匹配 A14：请按照以下几点检查： 分账接收商户全称填写错误，请填写正确的商户全称，商户全称对应进件接口中的字段“商户名称merchant_name”字段值没有加密，该字段值需要加密后上传，请正确加密后再提交。上传的中文全称乱码，请检查接口编码是否正确，接口需要使用UTF-8编码 Q15：分账调用“添加分账接收方接口”返回：账户不存在 ，请先点击充值 A15：账户未开通，请接收方商户在商户平台点击“充值”创建账户（商户平台-交易中心-充值） Q16：分账如果有退款怎么处理，是否可以回退？ A16：需注意以下几点： 已分出去的资金，在商户接收方同意的情况下，可以发起分账回退。（接收方可在“商户平台-交易中心-分账-分账接收设置”中开启同意分账回退） 更多分账订单退款逻辑，请查看文档说明 [图片]   Q17：分账调用“请求单次分账接口”返回：签名错误 A17：请按照以下几点检查： 使用签名检查工具校验签名算法是否有误确认秘钥是否有误（服务商模式使用服务商商户号秘钥，秘钥是在商户平台配置，如果同一商户号调用其它接口成功可排除是秘钥问题）确认接口实际的请求参数与生成签名原串的参数一致，不能增加或缺少参数（可通过打印签名原串进行排查）确认参数的大小写，参数名与接口文档一致签名原串的参数值使用原始值，不需要encode接口需要使用UTF-8编码 Q18：分账添加接收方接口，是在分账前添加一次，如果接收方无变化，后续是否还需要调用接口再添加 A18：是的，如果接收方没有变化，只需要添加一次即可 Q19：分账调用“查询分账结果接口”返回的分账单状态有几种 A19：有以下几点状态： ACCEPTED—受理成功 PROCESSING—处理中 FINISHED—处理完成 CLOSED—处理失败，已关单  Q20：在商户平台设置了分账动账通知url，为什么收不到通知 A20：请按照以下几点排查： 未设置动账通知url，该链接是通过商户平台【交易中心-分账接收设置】中配置的通知url，必须为https协议。如果链接无法访问，商户将无法接收到微信通知。必须为直接可访问的url，不能携带参数。示例：notify_url：https://pay.weixin.qq.com/wxpay/123456789商户未设置加密的密钥，请登录商户平台操作！请参考什么是APIv3密钥？如何设置？只有分账接收方才能收到分账动账通知，分账方是不会有通知的 Q21：分账调用“请求分账接口”返回：对同笔订单分账频率过高 A21：同笔订单多次分账频率是1秒1次，请降低频率后重试 Q22：分账后资金到可提现是否有中间状态 A22：没有中间状态 Q23：分账后的资金什么时候可提现 A23：分账后钱已经到商户的账户了，可以立刻提现 Q24：分账调用“完结分账接口”的作用是什么 A24: 调用该接口，可以将不需要进行分账的订单金额解冻给商户，解冻后的资金商户可自行发起提现 Q25：分账调用“分账回退接口”返回：参数不正确，请检查参数 A25：return_account与mch_id不能填写为相同的商户号，分账方与接收方商户号一致时，不需要回退 Q26：分账订单调用“申请退款接口”返回：申请退款金额大于剩余未分账金额，请等待分账完成后再试 A26：订单有过部分分账，退款金额不能大于剩余未分账金额，请调用“完结分账接口”解冻剩余资金后再发起退款 Q27：查询分账结果接口里面分账单状态（status）字段，当值为ACCEPTED时是表示分账成功了吗 A27：分账单的状态是表示分账单是否受理成功，并不代表分账是否成功。查看分账是否成功，需要调用查询分账结果接口，查看返回参数“分账接收方列表”里面的字段“分账结果result=SUCCESS”才是分账成功。 Q28：调用“添加分账接收方接口”一次可以添加多个接收方吗 A28：不可以，一次只能添加一个 Q29：请求分账接口返回：分账接收方不允许为分账出资方 A29：请按照以下几点检查： V2接口，“请求单次分账接口”分账接收方不允许为分账出资方，“请求多次分账接口”分账接收方可以为分账出资方V3接口，finish为true的情况，“请求分账接口”分账接收方不允许为分账出资方（这种场景，直接调完结分账API就好）。finish为false的情况，“请求分账接口”分账接收方可以为分账出资方 Q30：调用“请求分账接口”，分账分给多个接收方，会出现分账既有成功又有失败的情况吗 A30：同一次分账请求，会出现有的成功，有的失败的情况。具体请调用“查询分账结果接口”，查看返回参数“分账接收方列表”里面的字段“分账结果result=SUCCESS”才是分账成功。 Q31：“请求分账接口”分账接收方列表中的参数description会体现在分账账单里面吗 A31：在分账方分账账单和资金账单、分账接收方的资金账单里面都会体现 Q32：分账调用“添加分账接收方接口”返回：请求正在处理中，请稍后重试 A32：商户请求并发导致，重新再请求一次即可 Q33：分账调用“添加分账接收方接口”返回：商户已添加的分账接收方个数过多。请先删除多余的分账接收方，并在24小时之后再尝试添加 A33：添加分账接收方的个数限制是2W个，超过这个限制，请按照提示处理 Q34：电商收付通分账调用“请求分账回退接口”返回：可用余额不足，请充值后重新发起 A34：“回退商户号”的账户可用余额不足，需充值后再原单重试才能回退成功。（充值指引：登陆商户平台【交易中心】->【资金管理】->【充值/转入】，根据指引充值即可） Q35：电商收付通分账调用“请求分账回退接口”返回：可用余额不足，请充值后重新发起。这个时候，调用“查询分账回退结果API”却返回：PROCESSING（处理中），这个逻辑是正常的吗 A35：是正常的，逻辑就是这样的。这种情况，商户可以按照提示要求，提醒“回退商户号”充值后再原单重试即可回退成功 Q36：电商收付通分账调用“请求分账回退接口”返回：PROCESSING（处理中），什么情况会返回这种状态 A36：请参考以下几点： 网络抖动导致请求中断商户账户资金转账频繁，导致回退在排队时超时 Q37：电商收付通分账调用“查询分账回退结果接口”返回：TIME_OUT_CLOSED A37：TIME_OUT_CLOSED是fail状态了，也就是处于最终态，是不需要重试的。状态是SUCCESS也同理，也是最终态，不需要重试。返回TIME_OUT_CLOSED时可更换一个回退单，重新分账回退一次即可 Q38：电商收付通分账调用“请求分账接口”返回：分账补贴还未到账，不能受理分账 A38：报这个错误，是因为支付的订单在统一下单里面传了参数“补差金额：subsidy_amount”，传这个参数后，需要调用“请求补差API”完成补差，然后再调用“请求分账接口”即可正常分账 Q39：一笔交易在分账完成之后，将接收方和分账账户的绑定关系解除（删除分账接收方），然后进行分账回退，会成功吗 A39：会回退成功，不受删除分账关系的影响 这里的逻辑有两个： 这笔单曾经分给过了这个商户，且分账成功这个商户开通了分账回退 Q40：分账调用“分账回退接口”返回：PROCESSING A40：过一分钟后原单重试即可 Q41：分账回退有时间限制吗 A41：从订单创建的时间算起，现在分账回退限制180天以内的分账请求 Q42：分账方添加接口，如果相同的分账方重复提交，会返回添加失败，还是覆盖之前的分账方信息 A42：如果系统检测到已经绑定，那么会保留原来的数据，不更新数据，直接返回成功 Q43：在商户平台-管理分账接收方中手动添加分账接收方报错：系统错误，请稍后再试 A43：这个报错的原因是：账户未开通，请接收方商户在商户平台点击“充值”创建账户（商户平台-交易中心-充值） Q44：免充值和预充值的代金券，分账的时候，可分账的金额判断逻辑是一样的吗？比如10-5，使用了免充值代金券，可分账金额是5，使用了预充值代金券，可分账金额是10元还是5元呢 A44：不一样，使用了免充值代金券，可分账金额是5，使用了预充值代金券，可分账金额是10 Q45：电商收付通请求分账接口返回：appid与openid不匹配 A45：请求分账接口里面的APPID必须传电商平台服务商的APPID，所以商户在添加分账接收方时获取的openid，也必须是这个电商平台服务商APPID获取的openid Q46：请求分账回退接口返回：分账指令不存在，请检查是否有对应的分账单 A46：请按照以下几点排查： 分账回退里面的商户分账单号out_order_no，必须是请求分账接口的商户分账单号out_order_no请先调用查询分账回退结果API确认分账是否成功，分账成功的分账单才能调用回退接口正常回退。从订单创建的时间算起，分账回退限制180天以内的分账请求，超过180天不支持回退 Q47：查询订单待分账金额返回：记录不存在 A47：请按照以下几点排查： 记录不存在，可能是单号拼错了，请检查确认订单未结算，请在订单结算后再查询非分账订单，请检查订单支付时是否传了分账标识，传了分账标识的订单，才能正确查询 Q48：商户号能正常完结分账，但是查询分账结果却提示“无分账权限”。是什么原因？ A48：分账权限被冻结，请登陆商户平台查看站内信，按照指引申诉处理。 能正常完结分账的原因是：完结分账，就是将这笔订单的剩余的可分账的钱，都解冻给自己，由于这笔钱本来就是自己的，所以分账完结是一个安全的操作（钱没有给其他人，也没有给服务商，给了自己），所以是不会做权限校验的。当前要分出去给到别人时，就会做相关的权限校验了。 Q49：请求分账接口，当提交请求后返回报错SYSTEM_ERROR，这个时候调用查询分账结果接口查询，每10分钟查询一次，共查询3次（共30分钟）。这样的情况下，是否可以不用原单重试？查询后是否可以换单再提交？ A19：请求分账返回SYSTEM_ERROR时，调用查询分账结果接口3次（30分钟）后，查询结果仍然是不存在的情况：如果商户能保证在30分钟的窗口期内都不会重试，这样做是安全的。 但我们建议在返回SYSTEM_ERROR 情况下，商户还是原单重试，这种最安全，也不用查询和等待一个窗口期。 Q50：一个微信支付单被退完款，还可以继续分账吗？ A50：不可以了，分账是针对该订单冻结的金额进行分账，如果退完款，就不能再分账了。 Q51：比如一个订单支付金额是100.1元，假如手续费是0.1元。分账前先退款了30元，默认分账比例是30%，现在可以分账的金额还是30元，这样理解没有问题吧？ A51：没有问题 Q52：比如一个订单支付金额是100.1元，假如手续费是0.1元。分账前先退款了30元，默认分账比例是30%，现在可以分账的金额还是30元，那就是说，可能出现100退了80，分出去30这种情况？ A52：不会， 两个相加不会超过订单金额的， 也就是说退款没有超过70元的话，可分账金额是30，超过70，可分账金额是剩下的钱。 Q53：普通服务商分账，添加分账接收方这个APPID，如果服务商商户号绑定了两个APPID“B”和"C"，需要分账的订单统一下单中传的APPID是B，这个时候，添加分账接收方中的这APPID可以是“C”吗？还是说必须是“B”？ A53：请注意以下两点： 添加分账接收方的时候，B下的openid，C下的openid都可以但是执行分账的时候，一次分账请求里，只能是同一个appid下的openid，不支持一次分账请求里的openid分别是俩appid下的 Q54：查询分账结果接口返回：记录不存在 A54：请按照以下几点排查： 记录不存在，可能是单号拼错了，请检查确认订单未结算，请在订单结算后再查询非分账订单，请检查订单支付时是否传了分账标识，传了分账标识的订单，才能正确查询订单未分账，所以没有记录，请在订单分账后再查询

前言 自从iphoneX问世之后，因为iphoneX、iphoneXR和后续全面屏手机设备，因为物理Home键被底部小黑条代替了，这时候很多前端小伙伴在开发的过程都会遇到 “全面屏”和“非全面屏”的兼容性问题，普遍问题就是底部按钮或者选项卡与底部黑线重叠 解释 根据官方解释： 安全区域指的是一个可视窗口范围，处于安全区域的内容不受圆角(corners)、齐刘海(sensor housing)、小黑条(Home Indicator)的影响。 具体区域如图展示 [图片] 适配方案 当前有效的解决方式有几种 使用已知底部小黑条高度34px/68rpx来适配 使用苹果官方推出的css函数env()、constant()适配 使用微信官方API，getSystemInfo()中的safeArea对象进行适配 使用已知底部小黑条高度34px/68rpx来适配 这种方式是根据实践得出，通过物理方式测出iPhone底部的小黑条（Home Indicator）高度是34px，实际在开发者工具选中真机获取到高度也是34px，所以直接根据该值，设置margin-bottom、padding-bottom、height也能实现。同时这样做要有一个前提，需要判断当前机型是需要适配安全区域的机型。 但是这种方案相对来说是不推荐使用的。比较是一个比较古老原始的方案 使用苹果官方推出的css函数env()、constant()适配 这种方案是苹果官方推荐使用env()，constant()来适配，开发者不需要管数值具体是多少。 env和constant是IOS11新增特性，有4个预定义变量： safe-area-inset-left：安全区域距离左边边界的距离 safe-area-inset-right：安全区域距离右边边界的距离 safe-area-inset-top：安全区域距离顶部边界的距离 safe-area-inset-bottom ：安全距离底部边界的距离 具体用法如下： Tips: constant和env不能调换位置 [代码] padding-bottom: constant(safe-area-inset-bottom); /*兼容 IOS<11.2*/ padding-bottom: env(safe-area-inset-bottom); /*兼容 IOS>11.2*/ [代码] 其实利用这个能解决大部分的适配场景了，但是有时候开发需要自定义头部信息，这时候就没办法使用css来解决了 使用微信官方API，getSystemInfo()中的safeArea对象进行适配 通过 wx.getSystemInfo获取到各种安全区域信息，解析出具体的设备类型，通过设备类型做宽高自适应，话不多说，直接上代码 代码实现 [代码] const res = wx.getSystemInfoSync() const result = { ...res, bottomSafeHeight: 0, isIphoneX: false, isMi: false, isIphone: false, isIpad: false, isIOS: false, isHeightPhone: false, } const modelmes = result.model const system = result.system // 判断设备型号 if (modelmes.search('iPhone X') != -1 || modelmes.search('iPhone 11') != -1) { result.isIphoneX = true; } if (modelmes.search('MI') != -1) { result.isMi = true; } if (modelmes.search('iPhone') != -1) { result.isIphone = true; } if (modelmes.search('iPad') > -1) { result.isIpad = true; } let screenWidth = result.screenWidth let screenHeight = result.screenHeight // 宽高比自适应 screenWidth = Math.min(screenWidth, screenHeight) screenHeight = Math.max(screenWidth, screenHeight) const ipadDiff = Math.abs(screenHeight / screenWidth - 1.33333) if (ipadDiff < 0.01) { result.isIpad = true } if (result.isIphone || system.indexOf('iOS') > -1) { result.isIOS = true } const myCanvasWidth = (640 / 375) * result.screenWidth const myCanvasHeight = (1000 / 667) * result.screenHeight const scale = myCanvasWidth / myCanvasHeight if (scale < 0.64) { result.isHeightPhone = true } result.navHeight = result.statusBarHeight + 46 result.pageWidth = result.windowWidth result.pageHeight = result.windowHeight - result.navHeight if (!result.isIOS) { result.bottomSafeHeight = 0 } const capsuleInfo = wx.getMenuButtonBoundingClientRect() // 胶囊热区 = 胶囊和状态栏之间的留白 * 2 (保持胶囊和状态栏上下留白一致) * 2(设计上为了更好看) + 胶囊高度 const navbarHeight = (capsuleInfo.top - result.statusBarHeight) * 4 + capsuleInfo.height // 写入胶囊数据 result.capsuleInfo = capsuleInfo; // 安全区域 const safeArea = result.safeArea // 可视区域高度 - 适配横竖屏场景 const screenHeight = Math.max(result.screenHeight, result.screenWidth) const height = Math.max(safeArea.height, safeArea.width) // 状态栏高度 const statusBarHeight = result.statusBarHeight // 获取底部安全区域高度（全面屏手机） if (safeArea && height && screenHeight) { result.bottomSafeHeight = screenHeight - height - statusBarHeight if (result.bottomSafeHeight < 0) { result.bottomSafeHeight = 0 } } // 设置header高度 result.headerHeight = statusBarHeight + navbarHeight // 导航栏高度 result.navbarHeight = navbarHeight [代码]

背景 在做小程序时，关于默认导航栏，我们遇到了以下的问题： Android、IOS手机对于页面title的展示不一致，安卓title的显示不居中 页面的title只支持纯文本级别的样式控制，不能够做更丰富的title效果 左上角的事件无法监听、定制 路由导航单一，只能够返回上一页，深层级页面的返回不够友好 探索 小程序自定义导航栏已开放许久>>了解一下，相信不少小伙伴已使用过这个功能，同时不少小伙伴也会发现一些坑： 机型多如牛毛：自定义导航栏高度在不同机型始终无法达到视觉上的统一 调皮的胶囊按钮：导航栏元素（文字，图标等）怎么也对不齐那该死的胶囊按钮 各种尺寸的全面屏，奇怪的刘海屏，简直要抓狂 一探究竟 为了搞明白原理，我先去翻了官方文档，>>飞机，点过去是不是很惊喜，很意外，通篇大文尽然只有最下方的一张图片与这个问题有关，并且啥也看不清，汗汗汗… 我特意找了一张图片来 [图片] 分析上图，我得到如下信息： Android跟iOS有差异，表现在顶部到胶囊按钮之间的距离差了6pt 胶囊按钮高度为32pt， iOS和Android一致 动手分析 我们写一个状态栏，通过wx.getSystemInfoSync().statusBarHeight设置高度 Android： [图片] iOS:[图片] 可以看出，iOS胶囊按钮与状态栏之间距离为：4px， Android为8px，是不是所有手机都是这种情况呢？ 答案是:苹果手机确实都是4px,安卓大部分都是7和8 也会有其他的情况(可以自己打印getSystemInfo验证)如何快速便捷算出这个高度,请接着往下看 如何计算 导航栏分为状态栏和标题栏,只要能算出每台手机的导航栏高度问题就迎刃而解 导航栏高度 = 胶囊按钮高度 + 状态栏到胶囊按钮间距 * 2 + 状态栏高度 注：由于胶囊按钮是原生组件，为表现一致，其单位在各种手机中都为px，所以我们自定义导航栏的单位都必需是px（切记不能用rpx），才能完美适配。 解决问题 现在我们明白了原理，可以利用胶囊按钮的位置信息和statusBarHeight高度动态计算导航栏的高度，贴一个实现此功能最重要的方法 [代码]let systemInfo = wx.getSystemInfoSync(); let rect = wx.getMenuButtonBoundingClientRect ? wx.getMenuButtonBoundingClientRect() : null; //胶囊按钮位置信息 wx.getMenuButtonBoundingClientRect(); let navBarHeight = (function() { //导航栏高度 let gap = rect.top - systemInfo.statusBarHeight; //动态计算每台手机状态栏到胶囊按钮间距 return 2 * gap + rect.height; })(); [代码] gap信息就是不同的手机其状态栏到胶囊按钮间距，具体更多代码实现和使用demo请移步下方代码仓库，代码中还会有输入框文字跳动解决办法,安卓手机输入框文字飞出解决办法,左侧按钮边框太粗解决办法等等 胶囊信息报错和获取不到 问题就在于 getMenuButtonBoundingClientRect 这个方法，在某些机子和环境下会报错或者获取不到，对于此种情况完美可以模拟一个胶囊位置出来 [代码]try { rect = Taro.getMenuButtonBoundingClientRect ? Taro.getMenuButtonBoundingClientRect() : null; if (rect === null) { throw 'getMenuButtonBoundingClientRect error'; } //取值为0的情况 if (!rect.width) { throw 'getMenuButtonBoundingClientRect error'; } } catch (error) { let gap = ''; //胶囊按钮上下间距 使导航内容居中 let width = 96; //胶囊的宽度，android大部分96，ios为88 if (systemInfo.platform === 'android') { gap = 8; width = 96; } else if (systemInfo.platform === 'devtools') { if (ios) { gap = 5.5; //开发工具中ios手机 } else { gap = 7.5; //开发工具中android和其他手机 } } else { gap = 4; width = 88; } if (!systemInfo.statusBarHeight) { //开启wifi的情况下修复statusBarHeight值获取不到 systemInfo.statusBarHeight = systemInfo.screenHeight - systemInfo.windowHeight - 20; } rect = { //获取不到胶囊信息就自定义重置一个 bottom: systemInfo.statusBarHeight + gap + 32, height: 32, left: systemInfo.windowWidth - width - 10, right: systemInfo.windowWidth - 10, top: systemInfo.statusBarHeight + gap, width: width }; console.log('error', error); console.log('rect', rect); } [代码] 以上代码主要是借鉴了拼多多的默认值写法，android 机子中 gap 值大部分为 8，ios 都为 4，开发工具中 ios 为 5.5，android 为 7.5，这样处理之后自己模拟一个胶囊按钮的位置，这样在获取不到胶囊信息的情况下，可保证绝大多数机子完美显示导航头 吐槽 这么重要的问题，官方尽然没有提供解决方案…竟然提供了一张看不清的图片??? 网上有很多ios设置44，android设置48，还有根据不同的手机型号设置不同高度，通过长时间的开发和尝试，本人发现以上方案并不完美,并且bug很多 代码库 Taro组件gitHub地址详细用法请参考README 原生组件npm构建版本gitHub地址详细用法请参考README 原生组件简易版gitHub地址详细用法请参考README 由于本人精力有限，目前只计划发布维护好这2种组件，其他组件请自行修改代码，有问题请联系 备注 上方2种组件在最下方30多款手机测试情况表现良好 iPhone手机打电话和开热点导致导航栏样式错乱，问题已经解决啦，请去demo里测试，这里特别感谢moments网友提出的问题 本文章并无任何商业性质，如有侵权请联系本人修改或删除 文章少量部分内容是本人查询搜集而来 如有问题可以下方留言讨论，微信zhijunxh 比较 斗鱼: [图片] 虎牙: [图片] 微博: [图片] 酷狗: [图片] 知乎: [图片] [图片] 知乎是这里边做的最好的，但是我个人认为有几个可以优化的小问题 打电话或者开启热点导致样式错落，这也是大部门小程序的问题 导航栏下边距太小，看起来不舒服 搜索框距离2侧按钮组距离不对等 自定义返回和home按钮中的竖线颜色重了，并且感觉太粗 如果您看到了此篇文章，请赶快修改自己的代码，并运用在实践中吧 扫码体验我的小程序: [图片] 创作不易，如果对你有帮助，请移步Taro组件gitHub原生组件gitHub给个星星 star✨✨ 谢谢 测试信息 手机型号 胶囊位置信息 statusBarHeight 测试情况 iPhoneX 80 32 281 369 48 88 44 通过 iPhone8 plus 56 32 320 408 24 88 20 通过 iphone7 56 32 281 368 24 87 20 通过 iPhone6 plus 56 32 320 408 24 88 20 通过 iPhone6 56 32 281 368 24 87 20 通过 HUAWEI SLA-AL00 64 32 254 350 32 96 24 通过 HUAWEI VTR-AL00 64 32 254 350 32 96 24 通过 HUAWEI EVA-AL00 64 32 254 350 32 96 24 通过 HUAWEI EML-AL00 68 32 254 350 36 96 29 通过 HUAWEI VOG-AL00 65 32 254 350 33 96 25 通过 HUAWEI ATU-TL10 64 32 254 350 32 96 24 通过 HUAWEI SMARTISAN OS105 64 32 326 422 32 96 24 通过 XIAOMI MI6 59 28 265 352 31 87 23 通过 XIAOMI MI4LTE 60 32 254 350 28 96 20 通过 XIAOMI MIX3 74 32 287 383 42 96 35 通过 REDMI NOTE3 64 32 254 350 32 96 24 通过 REDMI NOTE4 64 32 254 350 32 96 24 通过 REDMI NOTE3 55 28 255 351 27 96 20 通过 REDMI 5plus 67 32 287 383 35 96 28 通过 MEIZU M571C 65 32 254 350 33 96 25 通过 MEIZU M6 NOTE 62 32 254 350 30 96 22 通过 MEIZU MX4 PRO 62 32 278 374 30 96 22 通过 OPPO A33 65 32 254 350 33 96 26 通过 OPPO R11 58 32 254 350 26 96 18 通过 VIVO Y55 64 32 254 350 32 96 24 通过 HONOR BLN-AL20 64 32 254 350 32 96 24 通过 HONOR NEM-AL10 59 28 265 352 31 87 24 通过 HONOR BND-AL10 64 32 254 350 32 96 24 通过 HONOR duk-al20 64 32 254 350 32 96 24 通过 SAMSUNG SM-G9550 64 32 305 401 32 96 24 通过 360 1801-A01 64 32 254 350 32 96 24 通过

文档地址：扣费服务 Q1:商户调用【申请扣款】接口返回"err_code:RULELIMIT,err_code_des:交易金额或次数超出限制，请检查后再试"是什么原因？ A1:商户扣款时超出了模板id配置的最大扣款金额或次数，如有需要可以联系微信运营申请提升额度或次数。 Q2:申请扣款周期说明 A2:请参考以下几点： 自动续费周期一般是以月、季度为周期，具体扣款发起时间不受模版内容的周期影响；委托代扣额度初始额度：单笔500、单日2500；授权扣款和免密支付，在额度限制内可以每天扣款5次（同一个用户在一个签约协议下；扣款失败不计算次数）；自动续费模版需要按模版内容设定的周期扣款，且同一个用户在一个签约协议下每天仅可以扣款一次，如上线前需多次测试签约扣款，请申请测试模版（模版名称标明为测试，测试模版限额为每次0.1元，每天可扣款100次）。 Q3:签约和解约信息是通过什么路径通知给商户的？ A3:签约通知是通过签约接口上传的notify_url参数所填写的地址回调通知的（签约失败不通知）。解约信息是通过创建模版ID时填写的解约通知URL来回调通知的。 Q4:申请扣款接口已经返回成功，为什么还会扣款失败？ A4：申请扣款接口返回成功仅代表申请受理成功，不代表最终的扣款结果，扣款结果应以支付结果通知接口通知的结果为准，无论扣款是否成功都会返回扣款结果及原因。 Q5:商户调起微信纯签约报错“参数构造错误”如图，是什么原因？ [图片] A5:检查下文档要求的必填参数有没漏传，或者文档中没有的参数有没多传。 Q6:商户调用H5纯签约返回“签约参数签名校验错误”是什么原因？ A6:请参考以下几点： 检查下签名是否正确，商户签名使用的key是否正确，并且key用的是api秘钥，不是apiv3秘钥,签名方式和api秘钥设置路径参看文档指引，商户可以用在线工具自行校验，工具地址；检查下商户传的notify_url参数文档是否有要求encode，如文档要求encode，则商户签名时需要使用encode之前原样的notify_url进行签名，encode只需一次即可。检查下文档要求的必填参数有没漏传，或者文档中没有的参数有没多传。 Q7:委托委托代扣模板id停用后会有什么影响？ A7:已签约用户可以继续扣费或解约，不能新增签约，停用模板id后无法恢复使用，商户自行评估风险 Q8:公众号纯签约跳转签约页面后用户点击开通自动续费没反应是什么原因？ A8:引导用户更新一下微信或清除下微信缓存，这种一般是偶现的，杀死进程重新启动再试试。 Q9:商户使用预扣费通知模式场景下，对于没有发送微信预扣费通知的用户，商户调用申请扣款接口后，微信端会返回什么错误？ A9:接口会返回错误码INVALID_REQUEST，商户需要先下发扣费前通知才能发起扣费，若当前签约扣费期已结束，商户如需扣费则需重新发起扣费前通知。 Q10:商户从24小时扣费模式迁移到预扣费通知模式阶段时，发送预扣费通知后，解约后重新签约，可直接进行扣款，不受扣费等待期限制，这样是正常的吗？ A10:正常的，用户解约后就是新的协议了，预扣费通知限制的维度是协议，没有发送过预扣费通知的协议，可以走直接扣费模式，发送过预扣费通知的协议，走预扣费通知模式，商户在迁移阶段，只有两种模式可以扣：预扣费通知模式和直接扣费模式，商户完成迁移后需联系微信侧运营确认，微信侧运营则会通知业管同事在系统中操作“迁移完成”，之后商户就只能走预扣费通知模式了。 Q11:预扣费通知中的错误码“RESOURCE_ALREADY_EXISTS”和“INVALID_REQUEST”的错误码描述意思是一样的，“RESOURCE_ALREADY_EXISTS”错误码描述为：已经下发过预扣费通知，请勿重复下发，“INVALID_REQUEST”错误码描述为：已经发送过扣费前通知，需要等本次扣费完成后再发起新，有什么区别吗？ A11:错误码“RESOURCE_ALREADY_EXISTS”表示是相同参数，重复发送，错误码“INVALID_REQUEST”表示是发送过，参数不一样。错误码“RESOURCE_ALREADY_EXISTS”可以认为是发送成功。错误码“INVALID_REQUEST”可以认为是发送失败。 Q12:一个微信用户能否与商户多次签约？ A12:签约遵循同一个商户号+同一个模版ID+同一个微信号只能签约一次的原则。多次签约可采用多模版ID的方式，同一个商户号下的每个不同模版ID都可以与同一微信用户分别签约一次。 Q13:委托代扣解约回调地址修改后多久生效？ A13:实时生效 Q14：商户使用微信支付商户平台发起的解约，收到的解约回调里的协议解约方式是3（商户API解约）这个是正常的吗？ A14:正常的，目前微信支付商户平台就是调用商户API解约的。 Q15:商户调起微信纯签约报错“签名参数构造错误”如图，是什么原因？ [图片] A15：请参考以下几点： 检查下签名是否正确，商户签名使用的key是否正确，并且key用的是api秘钥，不是apiv3秘钥,签名方式和api秘钥设置路径参看文档指引，商户可以用在线工具自行校验，工具地址；检查下商户传的notify_url参数文档是否有要求encode，如文档要求encode，则商户签名时需要使用encode之前原样的notify_url进行签名，encode只需一次即可。 Q16:支付中签约是否支持传入分账标识实现订单分账功能？ A16：暂不支持，支付中签约下单接口不会识别商户分账标识 Q17:单用户在单模板下商户尝试调用申请扣款接口的频率是多少？ A17：单用户在单模板下商户尝试调用申请扣款接口一天不能超过默认次数300次（包含succee和fail的返回，succee才表示扣款受理成功，等待扣款中） Q18:app纯签约点击完成后没有返回app而是停留在了微信聊天界面？ A18: 商户登录开放平台检查对应app应用是否有跳转权限[图片] 2.按照文档排查下是否正常处理回调，参看文档https://developers.weixin.qq.com/doc/oplatform/Mobile_App/Access_Guide/Android.html（注意：taskAffinity要填你的应用主taskAffinity（其实就是主界面的task，如果没有主动配置的话，默认是应用包名，如果要配置的，要改成跟配置的一样） [图片] 3.商户检查申请模板时的模版名称中是否有空格，如有只能删除模版名称中的空格后重新申请模板 [图片] 4.商户检查用户账户展示名称参数contract_display_account是否有空格，中英文符号，特殊字符串 Q19:app纯签约签约完成后，点击完成按钮，android点击没有反应，iOS点击提示“离开微信”，随后提示"未安装应用"? A19:请参考以下几点： 检查下商户传的appid是不是签约的这个app的appid检查返回的appid对应的app是否有安装检查商户的app是否有在手机注册schema地址 Q20:h5纯签约签约完成后点击完成按钮返回浏览器报错"launchApplication:fail_url need encode"？ [图片] A20：原因：商户请求签约的原url，里面参数嵌套了其它url地址，所以导致微信侧回跳的时候，解析错误了。这里面failUrl和redirectUrl虽然做了encode，但是由于微信侧回跳前会做一层decode，所以decode之后的链接是一个非法链接，被拦截了。如果商户需要嵌套url地址，可以做两层encode试试，建议解决方式：剔除参数中嵌套的url。 Q21:Url Schema指的是什么，UA指的是什么？ A21: url schenma指的是app页面跳转协议地址UA指的是浏览器的User Agent，会跟随HTTP协议的header传递 Q22:app纯签约接口是否支付多账号签约功能？ A22：支持，商户只需在app纯签约中的预签约接口里多传入outerid字段即可，参数值格式必须按照此示例：李*艳（00000000000），否者会报错"<xml><return_code><![CDATA[FAIL]]></return_code><return_msg<![CDATA[PARAMERROR:outerid]]></return_msg></xml>" Q23:多账号签约接口里的contract_outerid和outerid的长度限制分别是多少？ A23：contract_outerid32位字符，outerid32位字符 Q24:公众号纯签约商户的短链接可以跳转到签约页面，商户的长链接跳转报502是什么原因？ A24：链接超长，目前链接长度限制在1024字节以内 Q25:已签约同个模板id的用户使用支付中签约有已签约的提示吗？ A25：支付中签约一直都没有已签约的提示,纯签约会有提示 Q26:使用签约协议号A已签约后再解约，后续还可以使用签约协议号A签约成功吗，对吗？ A26：目前是这样的 Q27:商户调用支付中签约生成的订单使用的查询订单和支付回调结果通知是哪个文档？ A27：支付中签约生成的订单使用普通支付的查询订单接口(文档地址:https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=9_2)和普通支付的支付结果回调通知接口(文档地址:https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=9_7&index=8) Q28:开通多账号签约功能的模板id，如果同一个微信签约了两个用户，那么模板id扣款次数限制规则是不是应该按两个不同的签约用户分开计算 A28：是的，针对每个签约独立计算 Q29:同个微信号在同个模板下当天有扣款次数限制吗？ A29：同个微信号在同个模板下当天最多能扣150次，总共包含商户重试申请扣款失败的次数和申请扣款成功的次数 Q30:商户调用申请扣款接口报错“扣款请求已受理，请勿重复发起” A30：据自动续费规则，一个协议ID，在等待期间（24小时内），只能有一笔扣款 Q31:h5纯签约ios拉起签约后点击左上角返回的是微信，Android拉起签约后点击左上角返回的是拉起的签约页面，这是正常的吗 A31：这是正常的，Android 能返回是因为只拉起WebView界面，结束之后把WebVIew关了，然后就漏出了浏览器，iOS做不到只拉起WebView界面，结束之后只能到聊天页面 Q32:h5纯签约签约完成后点击完成按钮返回的是商户首页（域名），不是发起签约请求的页面 A32: 1.浏览器发起签约场景： 问题根因：referer由于客户端webview内核安全策略变更，需要源页面进行授权后，才能获取完整URL，否则无法在签约完成后，原路跳回商户的H5页面，浏览器由于兼容性问题导致微信侧获取的referer只有域名部分，丢失了path部分，所以返回的是商户域名页 微信支付侧协助寻找了以下解决方案，建议商户试试，如仍有问题需商户自行联系浏览器厂商处理： 商户跳转前的源H5页面，需要在html中做referrer-policy的授权声明： 方法一（推荐）： <meta name="referrer" content="no-referrer-when-downgrade">> 方法二： <meta name="referrer" content="unsafe-url"> 安全策略详情可参考：https://developers.google.com/web/updates/2020/07/referrer-policy-new-chrome-default Referrer-Policy声明的用法可参考：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Referrer-Policy 注意： ① 商户需要检查一下html里面是否有多个meta name="Referrer"的声明（比如声明了一个<meta name="Referrer" content="origin" />，会覆盖开头的声明，需要删掉） ② 检查发起签约页面跳转微信时是否有处理过（比如中转页面或着在后台跳转的），必须是商户前端发起的跳转，否则不会生效 ③由于iOS15对referrer policy更加严格，referer只带了host没有带path，但iOS14以及之前版本的referer带了host和path，导致了iOS15以上目前只能返回商户域名页面 2.商户发起签约页面地址中有片段标识符： 片段标识符（URI Fragment，即URL中#号后面的部分）仅用作浏览器端的处理，不会参与到服务端请求中，故签约完成回跳不会带上这部分信息。 Q33:app内嵌h5纯签约无法唤起微信的签约页面是什么原因？ A33：建议检查拉起微信的app是否有拒绝打开授权，历史上的case都是用户自己拒绝了唤起授权。 Q34:商户使用申请扣款（pay/pappayapply）下单成功后，再调用关单接口（/pay/closeorder）成功后，之后再使用代扣的查询订单接口（/pay/paporderquery）查不到这笔订单，报错”订单不是委托代扣场景“，目前有什么解决方式吗？ A34：商户可以使用基础支付的查询订单接口来确认订单状态。 Q35:商户app内嵌h5发起h5纯签约签约完成后，申请了返回app的权限，返回app时提示“launchApplication:fail”，是什么原因？ A35：原因是商户配置的app的Schema有误导致无法正常跳回app，商户可以联系app的开发人员检查下操作系统中是否有注册这个Schema以及配置的appid是否正确。  Q36:商户调起微信纯签约报错“商家系统错误，请联系商家处理”如图，是什么原因？ [图片] A36：请参考以下几点： 检查下签名是否正确，商户签名使用的key是否正确，并且key用的是api秘钥，不是apiv3秘钥,签名方式和api秘钥设置路径参看文档指引，商户可以用在线工具自行校验，工具地址；检查下商户传的notify_url参数文档是否有要求encode，如文档要求encode，则商户签名时需要使用encode之前原样的notify_url进行签名，encode只需一次即可。检查下文档要求的必填参数有没漏传，或者文档中没有的参数有没多传。h5纯签约的情况需要特殊申请权限，联系对接的运营咨询检查request_serial(请求序列号)或timestamp(时间戳)是否为int类型，是否小于9位