https://developers.weixin.qq.com/miniprogram/introduction/plugin.html 这个有收费标准吗? 如果是接入第三方之类的,api收费标准

写在开头： 其实微信支付侧在很早～很早～～很早～～～之前就打算将平台证书抛弃改换公钥模式进行敏感信息加密和回调签名验证了，平台证书只有5年有效期，现在的开发者只会管当下“能run就行”，哪会考虑到5年之后平台证书过期的事情，导致在首次平台证书过期时间点（2023年末2024年初）很多线上平稳运营多年的系统就突然炸了，还一时不容易定位问题。 在解决平台证书问题上，微信支付推出了新的公钥模式，由于前期一直在各种线下会议上宣传，没有给出正式通知和明确的使用指引，高估了大部分开发者的情况，再加上很突然的线上灰度，盲猜内部没协调好引发新申请商户号调用“获取平台证书”接口出现已读乱回的情况，社区因此出现大量此类报错提问，可以看出很多开发着开始迷茫了：“我是谁？我在哪？为啥同样代码其他商户号都正常？为啥我’差不多‘时间申请的商户号其他的能有，就这不能用？”。 出于作为“用爱发电的热心网友”，就简单写个让大家能看得懂的说明吧。 PS：其实我们要感谢微信支付团队，给各位开发者多找点事情做，避免大家被“毕业”，要感谢他们的良苦用心～！ 吐槽两句 真不知道负责这块接口设计的人是咋想的，在不知情需要获取公钥的情况下，你获取平台证书接口提示个“证书不存在”是写给谁看？写的报错提示谁能直接看得出来你想表达的意思？脑回路清奇，建议拉出去弹吉他十分钟！！！ 问题说明 微信支付对于新申请商户号以及平台证书过期商户已不再签发平台证书，需要更换使用微信支付平台公钥进行敏感信息加密、通知回调签名验证，因此此类商户号调用获取平台证书接口时会出现报错“证书不存在”或者“系统繁忙”的情况。 解决方案 目前会存在两种情况，一种是新申请商户号商户后台没有“平台证书”管理入口，另一种为存量商户存在有在有效期的平台证书和平台证书过期没有签发，第一种可以直接在商户后台->账户中心->API安全->启用“微信支付公钥”，下面教程主要以存量商户切换公钥进行说明（懒得申请新商户号了，拿个白名单商户来写的）。 1.1获取商户对应的平台公钥 商户后台->账户中心->API安全->申请“微信支付公钥“，在点击申请的时候会提示你查看指引，要点查看才可以进行公钥申请！！！ [图片] 下载公钥 [图片] 点击“下载公钥”后会自动下载文件名为’pub_key.pem’的公钥并在后台生成“PUB_KEY_ID”开头的公钥ID（丢了也没事，后台可以重复下载，公钥ID不变） [图片] 1.2 接口开发 下面所写示例说明均使用官方sdk，仅供参考 PHP 同时支持平台证书和平台公钥两种方法，在返回的wechatpay-serial值，在certs里有定义，就会自动匹配 [代码]// 从本地文件中加载「微信支付平台证书」或者「微信支付平台公钥」，用来验证微信支付应答的签名,这里直接使用前面从后台获取的微信支付平台公钥; $platformCertificateOrPublicKeyFilePath = 'file:///path/to/wechatpay/certificate_or_publickey.pem'; $platformPublicKeyInstance = Rsa::from($platformCertificateOrPublicKeyFilePath, Rsa::KEY_TYPE_PUBLIC); // 「微信支付平台证书」的「证书序列号」或者是「微信支付平台公钥ID」 // 「平台证书序列号」及/或「平台公钥ID」可以从 商户平台 -> 账户中心 -> API安全 直接查询到,这里直接写前面从后台获取的微信支付平台公钥ID，注意要带上'PUB_KEY_ID_' $platformCertificateSerialOrPublicKeyId = 'PUB_KEY_ID_0114232134912410000000000000'; [代码] java 将原“RSAAutoCertificateConfig.Builder”配置改为使用“RSAPublicKeyConfig.Builder”，publicKeyId填写前面从后台获取的微信支付平台公钥ID，注意要带上’PUB_KEY_ID_’ [代码]// 可以根据实际情况使用publicKeyFromPath或publicKey加载公钥 Config config = new RSAPublicKeyConfig.Builder() .merchantId(merchantId) .privateKeyFromPath(privateKeyPath) .publicKeyFromPath(publicKeyPath) .publicKeyId(publicKeyId) .merchantSerialNumber(merchantSerialNumber) .apiV3Key(apiV3Key) .build(); [代码] go 仅可使用微信支付的公钥验证应答和回调的签名,使用公钥ID初始化 [代码]var ( wechatpayPublicKeyID string = "PUB_KEY_ID_0114232134912410000000000000" // 微信支付公钥ID ) wechatpayPublicKey, err = utils.LoadPublicKeyWithPath("/path/to/wechatpay/pub_key.pem") if err != nil { panic(fmt.Errorf("load wechatpay public key err:%s", err.Error())) } // 初始化 Client opts := []core.ClientOption{ option.WithWechatPayPublicKeyAuthCipher( mchID, mchCertificateSerialNumber, mchPrivateKey, wechatpayPublicKeyID, wechatpayPublicKey), } client, err := core.NewClient(ctx, opts...) // 初始化 notify.Handler handler := notify.NewNotifyHandler( mchAPIv3Key, verifiers.NewSHA256WithRSAPubkeyVerifier(wechatpayPublicKeyID, *wechatPayPublicKey)) [代码] 1.3以上是使用sdk的参考，不使用sdk的情况下，可以参考下面链接内的示例（应该能跑，没测试）：点我查看 1.4 开发对接完成后，在商户后台更换验签方式 此操作可在灰度完成之前操作终止，操作需要超管进行操作并进行安全验证，更换以后回调灰度进度由平台控制在7天内完成，应答进度由商户请求参数控制，更换完成后才可以进行平台证书作废操作。 [图片] 就这样吧，有什么问题跟帖回复

登录相关 https://mp.weixin.qq.com https://open.weixin.qq.com https://long.open.weixin.qq.com https://lp.open.weixin.qq.com 主服务器 https://servicewechat.com CDN https://dldir1.qq.com https://res.wx.qq.com https://res.servicewechat.com (基础库下载地址) 云开发相关 https://tcb.cloud.tencent.com https://scf.tencentcloudapi.com https://flexdb.tencentcloudapi.com https://tcb.tencentcloudapi.com 真机调试 wss://wxagame.weixin.qq.com 帧同步服务器 https://long.wxagame.weixin.qq.com 上报相关 https://cube.weixinbridge.com https://repot.url.cn

本篇是对微信官方文档进行补充，一般需要消息解密的场景主要有如下几种： 第三方平台的消息推送：https://developers.weixin.qq.com/doc/oplatform/Third-party_Platforms/2.0/api/Before_Develop/message_push.html网站应用的消息推送：https://developers.weixin.qq.com/doc/oplatform/Website_App/WeChat_Login/message_push.html移动应用的消息推送：https://developers.weixin.qq.com/doc/oplatform/Mobile_App/WeChat_Login/message_push.html公众号接收用户消息：https://developers.weixin.qq.com/doc/offiaccount/Message_Management/Receiving_standard_messages.html公众号接收事件推送：https://developers.weixin.qq.com/doc/offiaccount/Message_Management/Receiving_event_pushes.html小程序接收用户消息和事件：https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/customer-message/receive.html你需要按照各自指引文档，开放你的服务器 http 服务，通过在管理后台配置你服务器的指定路径和加密参数，来和微信服务确定消息的沟通事宜。 [图片] 一般涉及到加密消息的只有 Token 和 EncodeingAESKey 两个，只需要保证你的服务器加解密的信息和微信服务的一致即可，所以这个你可以指定。 指定加密信息和服务器路径之后，微信服务器会按照你的加密信息对原始数据进行加密，然后向你指定的 http 服务路径中发送 post 请求。 当你的服务器收到微信服务器发来的请求时，你应该能得到直接拼在请求路径里的 query 参数 比如你的路径为：https://www.example.com/wxmp/ 那么实际收到的应该是： https://www.example.com/wxmp/?signature=f464b24fc39322e44b38aa78f5edd27bd1441696&echostr=4375120948345356249&timestamp=1714036504&nonce=1514711492 你可以将 query 参数拿出来，以备后面解密使用。 另外在请求的 body 中，是一个 base64 编码数据（如果你选择的明文模式，收到的可能是明文） 你需要先解析一下这个 base64 数据，得到一个 xml 或者 json 类型的明文数据，里面有两个东西： Appid，这个消息应该所属的应用id（小程序、公众号、第三方平台、移动应用、网站应用、企业微信等）Encrypt，真正的消息体（加密过的，我们后面需要解密）接下来我们就对比 Appid 是否是我们的应用，如果是则继续处理消息体；如果不是就直接丢掉。 处理消息体前，我们需要先验证一下真实性，对 Encrypt 内容进行签名（需要用到配置的 Token，以及 query 里的 timestamp、nonce ），看下是否和 query 参数里提供的 signature （前面如果有加密的话，这里应该是 msg_signature）相同，不同则证明被篡改或者解密信息对应，也没必要继续解了。 如果签名一致，我们就可以继续解密 Encrypt 内容。 解密需要用到一开始配置的 EncodeingAESKey ，AES 使用 CBC 模式，具体的可以直接参考代码： 代码包下载：https://wximg.gtimg.com/shake_tv/mpwiki/cryptoDemo.zip 上面链接代码包里没有 NodeJS，考虑到相当部分的开发者都用 NodeJS 来开发服务端，所以这里提供最小代码，方便参照设计自己的解密模块。 代码可以直接复制下来运行，需要额外安装 xml2js 模块，最后部分为测试实例（里面的 token 和 key 信息都脱敏过，不需要担心） const crypto = require('crypto') const xml2js = require('xml2js') const xmlparser = new xml2js.Parser() const ALGORITHM = 'aes-256-cbc' // 使用的加密算法 const MSG_LENGTH_SIZE = 4 // 存放消息体尺寸的空间大小。单位：字节 const RANDOM_BYTES_SIZE = 16 // 随机数据的大小。单位：字节 /** * 解密数据 * @param {*} encryptdMsg 加密消息体 * @param {*} encodingAESKey AES 加密密钥 * @returns */ function decode (encryptdMsg, encodingAESKey) { const key = Buffer.from(encodingAESKey + '=', 'base64') // 解码密钥 const iv = key.subarray(0, 16) // 初始化向量为密钥的前16字节 const encryptedMsgBuf = Buffer.from(encryptdMsg, 'base64') // 将 base64 编码的数据转成 buffer const decipher = crypto.createDecipheriv(ALGORITHM, key, iv) // 创建解密器实例 decipher.setAutoPadding(false) // 禁用默认的数据填充方式 let decryptdBuf = Buffer.concat([decipher.update(encryptedMsgBuf), decipher.final()]) // 解密后的数据 const padSize = decryptdBuf[decryptdBuf.length - 1] decryptdBuf = decryptdBuf.subarray(0, decryptdBuf.length - padSize) // 去除填充的数据 const msgSize = decryptdBuf.readUInt32BE(RANDOM_BYTES_SIZE) // 根据指定偏移值，从 buffer 中读取消息体的大小，单位：字节 const msgBufStartPos = RANDOM_BYTES_SIZE + MSG_LENGTH_SIZE // 消息体的起始位置 const msgBufEndPos = msgBufStartPos + msgSize // 消息体的结束位置 const msgBuf = decryptdBuf.subarray(msgBufStartPos, msgBufEndPos) // 从 buffer 中提取消息体 return msgBuf.toString() // 将消息体转成字符串，并返回数据 } /** * 生成签名 * @param {*} encrypt 加密消息体 * @param {*} timestamp 时间戳 * @param {*} nonce 随机数 * @param {*} token 令牌 * @returns */ function genSign (encrypt, timestamp, nonce, token) { const rawStr = [token, timestamp, nonce, encrypt].sort().join('') // 原始字符串 const signature = crypto.createHash('sha1').update(rawStr).digest('hex') // 计算签名 return signature } // --------------------------- 以下为测试代码 --------------------------- // 与微信后台的 encodingAESKey 保持一致 const encodingAESKey = "KE66t5p56ig2rz66Ep2H6bTiitgP2ib26GbuT9tumBB" // 与微信后台的 token 保持一致 const token = "fjKCjCksHwYwHZWARPgtjKKYZyRAstkr" // 你的服务器会收到微信服务器发送的消息，这是 query 参数 const query = { signature: 'eab668051feb6330f0f84e9a9b0bc8d9d972c049', // 有些平台会对加密消息体再做一层 base64，这里就是此 base64 的签名，否则就是真的加密消息体的签名 timestamp: '1721800206', // 签名要用 nonce: '1727131331', // 签名要用 encrypt_type: 'aes', // 有些平台会有特殊加解密方式，请参考实际文档，默认 aes_cbc msg_signature: '31c02ec801f178b72e712427a64a59be01ebec5a' // 有些平台会对加密消息体再做一层 base64，所以这里有提供就是真的加密消息体的签名 } // 你的服务器会收到微信服务器发送的消息，这是 body 参数，绝大部分会是 xml 消息体，有时会做一层 base64 编码 // 需要先 base64 解码，然后得到 xml 解析，xml 中会包含 Appid 和 Encrypt 两个，你需要验证 Appid 是你自己的，并且只取 Encrypt 中的内容就好，下面是内容。 const body = 'Sk+nxj+6bfJYOu1zmckuQhxVPaT9IRHA3C4wmNAJvYa7oBmxBg6nETY8dv7nWw9O8N2VbJYcANjBfDeGXOySKweRlEUHbDEzsHprI3A1WY6H73v4lg97TPyTudYVNDvY6ve4hEwlkxgx8WOl7Jd9HbpuIZJ4711CQuJQNuQyONkBFBXxQXuyIurthDv9/pxKYwnmV/NZQF6LKyuezAfjyoz35lqK7QgnfCW6kAB5wAiYOaW0CK4/4b9jo9J40jPumvs4d9Wa+t4Xzh1a8R6ogCTlw6EQSKGqEbKblSI8p0Dc2QDzEuRO+1qlcnoHmaacf14aL41Y148n6lObt9YPsTWI4CZNA0C4P7mPVsWd1v63vHTk4shI6VanpTruIjhdAEiWbeg+rFU5CQj5+0V0QJpQOQasFW9T4VW2m8s85isB9f4A91Q3+6bAoWlHBqj6c8tAnQzxtjMAJZDX2SNCov+B3kICZke2FLE+OhUVNxnsaETJ++EFUTwE7kOzgSGRen9Shnsi3CHEHSDLtveUavzfS33RWQzRSTGsZc++0ZNKrI1pgVR4Oew4WQgHGDxlRiVPeNvPFMD36V72ZE/0BSLdW3It/9TK34rLTx6xv7952VJ/gYKbTq0LBvvrt6YaFMJdPsnZlix8TUfNXRZN/MNsNJPOj4B+PgkU5duxbYc0bHvcA7oUlWnm3vSpIHaGBBsrsRaMAXLqluky9zM0l4fcS93Cyjcgt/eS7QkZWVpLKrtBkj2OmN0plBJNv8MiRcM/GX0BcHSBlyXeXbO/4vkkTRgKGbjLAWRBff8iP9j0RziTyVZ/i08QO79k0dXPrY/SON4wtVagHdU2FZ8pQA==' // 你需要自己计算一下消息的签名，并和微信服务器计算出来的签名进行比较。 const signature = genSign(body, query.timestamp, query.nonce, token) console.log('本地计算的签名：', signature) console.log('微信服务器计算的签名：', query.msg_signature) // 如果相同，说明消息是微信服务器发来的，否则说明消息不是微信服务器发来的 if(signature === query.msg_signature){ const result = decode(body, encodingAESKey) console.log('解密后的数据', result) // 如果是 XML 格式，可能比较难处理，所以下一步转换为 JSON，如果指定微信服务器发送JSON格式，可以忽略 xmlparser.parseStringPromise(result).then(res=>console.log('最终数据', res.xml)) } else { console.log('签名不一致') }

在 Skyline 支持了长列表按需渲染之后，还是有很多开发者对于按需渲染表示疑惑：   开发者A：scroll-view 下拉不太流畅 开发者B：list-view 有什么作用呢？ 开发者C：关于长列表的按需渲染功能，我们如何能检测到这个功能正确触发了呢？   关于以上几个问题，我们一一来解答： Q：scroll-view 下拉不太流畅？  当发现 scrll-view 下拉不够流畅时，可能是用法不对导致的不流畅。 根据 type 不同，按需渲染的用法也不同，建议按以下方式检查一下 type="list" : 根据直接子节点是否在屏来按需渲染type="custom" : 只渲染在屏节点，对于列表、网格、瀑布流等，子节点必须包裹在 list-view、grid-view 内部才会按需渲染。  Q：list-view 有什么作用呢？ 对于 list-view、grid-view 等 *-view 组件，符合规定的写法则会按需渲染。 默认情况下，视口外节点不渲染。也可以根据业务需要，设置 scroll-view 的 cache-extent 指定视口外渲染区域的距离来优化滚动体验和加载速度。 [图片] 当然 cache-extent 越大也会提高内存占用且影响首屏速度，建议大家按需启用。   Q：关于长列表的按需渲染功能，我们如何能检测到这个功能正确触发了呢？ 当使用按需渲染时，例如下面用的 type="list"，其实直接子节点都是一开始就创建的，所以没有办法从开发者工具检查到这个功能正常触发。 [图片] 不过可以在真机上开启 “开发调试 - Debug Skyline - checkerboardRasterCacheImages” 调试 [图片] 当滚动 view 离开屏幕回来之后颜色变了，说明节点重新渲染了，以此来确认按需渲染功能正确触发 👇例如下图中第一个节点，一开始是紫色，当离开屏幕重新滚动回屏幕时，变成了黄色，证明按需渲染成功～ 注意：不是所有的组件都会形成 RasterCache，需要结构复杂一些才会； [图片] *-builder 组件  除了 *-view 组件，很多开发者应该也注意到了 *-builder 组件 list-view 对应 list-buildergrid-view 对应 grid-builder看文档描述的能力是一样的，但是为什么会分成两个组件呢？ 因为目前 *-view 组件是按需渲染，节点还是会不断的创建，当长列表越来越长时，内存占用会越来越多。 于是我们新增了 *-builder 组件来支持 scroll-view 的可回收，可以更大程度降低创建节点的开销。 我们来看下效果，可以从开发者工具的 wxml 看到，当列表滚动时，list-builder 中渲染的 view 节点只有在屏的几个 [图片] 除了使用 wxml 板块查看之外，*-builder 组件还提供了监听事件，开发者可以监听列表创建和回收 binditembuild：列表项创建时触发，event.detail = {index}，index 即被创建的列表项序号binditemdispose：列表项回收时触发，event.detail = {index}，index 即被回收的列表项序号 使用场景既然 *-builder 组件拥有回收+创建能力，是不是可以不用 *-view 组件啦？ 当然不是啦～～～ 回收+创建能力本身就是有开销的，所以也要根据业务场景按需使用哦 *-builder：对于长列表、无限滚动列表等，或者节点内存占用高的，每个时刻都确保不会有太多节点创建出来，使用 *-builder 可以节省内存*-view：对于短列表，或者内存占用不高的列表则比较适合使用 *-view  代码片段：https://developers.weixin.qq.com/s/rp07iKmW7UQS

备案材料准备 在提交备案前，请务必提前准备好备案所需材料，以免由于材料更新问题，导致备案需延期提交。下面将会带大家详细了解备案材料的要求，这样后续在提交时就能避免因为材料问题而导致失败。 材料示例及注意事项 [图片] 注：所有上传材料大小应不超过2M，分辨率不低于720* 1280 ，仅支持JPG、JPEG、PNG 格式 若想查看更多小程序备案材料示例，详情可查看文档 备案信息填写 备案材料准备好后，就可以前往【小程序管理后台-设置-小程序备案】提交备案申请了。下面将会详细教大家如何进行备案信息的填写，一共分为五个部分：主办单位信息填写、主体负责人信息填写、小程序信息填写、小程序管理员信息填写和上传其他信息材料。 1.主办单位信息填写 [图片] [图片] 填写说明 常见报错/问题 解决方案 ①选择地区：选择与证件地址相一致的省市区信息 该主体已在XX完成备案，请修改备案省份或注销备案主体重新备案 请核实该主体是否有在其他省份备案过，由于同主体在所有平台的备案省份必须保持一致，需修改备案省份或注销备案主体重新备案 ②主办者性质：默认与小程序主体认证信息相一致 / / ③证件类型：默认与小程序主体认证信息相一致 / / ④上传证件：按要求提供最新版证件 营业执照有效期不足 请联系工商部门更新证件有效期 ⑤企业名称：填写证件相对应名称信息 主办者与小程序主体不一致 请核实填写企业名称是否与小程序主体名称、上传营业执照名称相一致 ⑤企业名称：填写证件相对应名称信息 营业执照名称为空或者* 号 请联系工商部门更新企业名称信息 ⑥证件住所：填写证件相对应经营场所信息 【主体证件住所】工商数据对比不通过 请参考文档进行排查 ⑦证件号码：填写证件相对应统一社会信用代码信息 未查询到企业信息，请检查主体证件号是否有误 请核实填写的是否为统一社会信用代码，若无，请联系工商部门更新证件信息，不能填写其他如工商注册号等 ⑧通讯地址：填写当前主体所在的实际通讯地址（无需填写省、市、区） 通讯地址未能精确到门牌号 若无具体门牌号，需要在备注中说明情况 ⑨备注（选填）：针对主体信息进行补充说明，如有可填写 / / 注：若为新建企业或近期有做信息变更，可能会存在企业工商数据更新延迟的情况，建议过段时间（5~15个工作日）再进行重试，否则无法正常发起验证流程。 2.主体负责人信息填写 [图片] 填写说明 常见报错/问题 解决方案 ①证件类型：选择主体负责人证件类型信息 / / ②上传证件：按要求提供最新版证件 / / ③负责人名称：通过上传证件自动识别，有误可自行修改 主体负责人与法定代表人不一致，且备案所在地不支持法定代表人授权 请核实填写的主体负责人是否为法人，需与营业执照信息一致，由于所属地区不支持授权，只能填写法人信息 ④负责人证件号：通过上传证件自动识别，有误可自行修改 【主体负责人证件号码】企业工商四要素核验失败 请核实填写的主体负责人名称、证件号信息是否正确 ⑤证件有效期：通过上传证件自动识别，有误可自行修改 / / ⑥手机号：主体负责人手机号码 【主体负责人手机号码】不允许被多人使用 请核实填写的手机号是否为其他人的信息，仅在同一主体下，同一个人允许为多个小程序备案，可提交一致的手机号、应急手机号及邮箱信息，否则不能出现个人信息混用的情况 ⑦验证码：主体负责人手机号码收到的对应验证码 验证码不正确 请核实验证码是否已失效，验证码有效期为10分钟 ⑧应急手机号：主体负责人的应急电话 【主体负责人应急联系方式】不允许被多人使用 请核实填写的应急手机号是否为其他人的信息，仅在同一主体下，同一个人允许为多个小程序备案，可提交一致的手机号、应急手机号及邮箱信息，否则不能出现个人信息混用的情况 ⑨邮箱地址：主体负责人的电子邮箱 / / 3.小程序信息填写 [图片] 填写说明 常见报错/问题 解决方案 ①服务内容标识：根据小程序实际运营内容选择合适的即可 小程序服务内容类型数目不能超过5个 服务内容标识是通信管局对各个行业的分类，平台部分行业类目与管局行业类目名称不完全不一致，建议根据备案小程序实际运营内容尽可能选择对应的服务内容标识，最多选择5个。 ②互联网信息服务前置审批项：根据小程序实际运营内容判断是否需要进行前置审批 如从事XXX业务，请上传前置审批文件 小程序实际运营内容涉及前置审批项，需上传对应的审批文件 ②互联网信息服务前置审批项：根据小程序实际运营内容判断是否需要进行前置审批 前置审批项必须选择“以上都不涉及” 小程序实际运营内容不涉及前置审批项，需要选择"以上都不涉及” ③备注（必填）：具体描述小程序实际经营内容，主要服务内容 请在小程序备注按格式填写 请核实是否有根据备注格式进行填写，仅自行补充带星号内容即可。 4.小程序管理员信息填写 [图片] 填写说明 常见报错/问题 解决方案 ①证件类型：选择小程序负责人证件类型信息（目前仅支持身份证） / / ②上传证件：按要求提供最新版证件（目前仅支持身份证） / / ③负责人名称：通过上传证件自动识别，有误可自行修改 【小程序负责人姓名】负责人与小程序管理员不一致 请核实小程序是否未完善管理员实名信息，需参考指引文档进行补充 ④负责人证件号：通过上传证件自动识别，有误可自行修改 【小程序负责人证件号码】负责人与小程序管理员不一致 请核实小程序是否未完善管理员实名信息，需参考指引文档进行补充 ⑤证件有效期：通过上传证件自动识别，有误可自行修改 / / ⑥手机号：小程序负责人手机号码 【小程序负责人手机号码】不允许被多人使用 请核实填写的手机号是否为其他人的信息，仅在同一主体下，同一个人允许为多个小程序备案，可提交一致的手机号、应急手机号及邮箱信息，否则不能出现个人信息混用的情况 ⑦验证码：小程序负责人手机号码收到的对应验证码 验证码不正确 请核实验证码是否已失效，验证码有效期为10分钟 ⑧应急手机号：小程序负责人的应急电话 【小程序负责人应急联系方式】不允许被多人使用 请核实填写的应急手机号是否为其他人的信息，仅在同一主体下，同一个人允许为多个小程序备案，可提交一致的手机号、应急手机号及邮箱信息，否则不能出现个人信息混用的情况 ⑨邮箱地址：小程序负责人的电子邮箱 / / ⑩负责人人脸核身：小程序管理员（小程序负责人）需使用微信APP扫码，完成人脸核身 当前场景仅支持居民身份证 核实小程序管理员证件是否为大陆居民身份证，目前港澳台管理员无法进行人脸核身，建议先更换小程序管理员为中国大陆地区的人员，作为备案小程序负责人。 5.上传其他信息材料 [图片] 填写说明 常见报错/问题 解决方案 互联网信息服务承诺书：1. 广东地区：下载页面提供的模版文件，填写完整后上传提交；2. 非广东地区：点击阅读确认后提交 承诺书需加盖公章，但个体户没有公章 若个体工商户无公章，需要主体负责人手写日期+签名+盖手印+身份证号码，同时请在主体备注处备注“个体工商户无公章”。注：江苏、宁夏、福建地区，须刻章后提交备案，不接受负责人手印。 以上信息都填写完毕，就可点击提交，后续的备案审核流程可参考： [图片] 如有其他相关疑问，欢迎随时参与社区讨论。

[图片] 在过去的小程序开发过程中，全局工具栏一直是开发者们急需解决的问题。然而，小程序并未直接支持此功能，开发者们只能采用自定义组件方式来实现。这种方法需要在每个页面的 wxml 中引入组件，导致大量重复代码，同时状态同步过程复杂且不够顺滑，给开发者带来了很大的困扰。 为了解决这个头疼的问题，Skyline 已经支持了小程序全局工具栏功能。这个全新的功能将大大简化开发流程，提升用户体验和操作便利性。全局工具栏可以实现跨页面渲染和状态同步，其渲染层级位于页面之上，使得用户在不同页面间切换时，工具栏的状态能得到保持，大大增强了操作的便利性。 接下来的文章中，我们将详细介绍小程序全局工具栏的使用流程，希望能帮助开发者们更好地理解和应用这一强大的功能～ 使用步骤通过以下三个步骤，你将能够轻松实现全局工具栏的功能： 1、配置信息：首先，在 app.json 文件中添加 appBar 选项，如下所示： { "appBar": {} }   2、添加 appBar 代码文件：在代码根目录下添加入口文件，包括以下四个文件： app-bar/index.js app-bar/index.json app-bar/index.wxml app-bar/index.wxss   3、编写 appBar 代码：使用自定义组件的方式编写 appBar 代码。在 app-bar/index.js 文件中，创建一个自定义组件实例，并在 app-bar/index.wxml 文件中编写组件的结构。同时，可以在 app-bar/index.wxss 文件中添加样式。最后，在需要获取 appBar 组件实例的页面中，使用 getAppBar 接口获取实例，进行操作。例如： Page({ getInstance() { if (typeof this.getAppBar === 'function') { const appBarComp = this.getAppBar(); appBarComp.setData({}); } } });   通过以上三个步骤，你已经成功实现小程序全局工具栏，从而简化开发流程并提升用户体验和操作便利性～ 注意事项和限制在使用小程序全局工具栏时，我们需要关注以下几点注意事项和限制，以确保功能的正常运行： app-bar 组件仅支持 Skyline 渲染，Webview 渲染不支持，需确保项目采用 Skyline 渲染引擎以实现全局工具栏功能。在 Webview 渲染和 Skyline 渲染之间混跳时，全局工具栏的状态同步会受到影响，需要注意在跳转页面时处理状态变化。由于全局工具栏的渲染层级位于页面之上，需要避免与其他页面元素发生层叠覆盖，确保留出足够的空间容纳全局工具栏，避免影响用户体验。全局工具栏功能需要 v3.3.1 及以上的小程序基础库版本支持。遵循以上注意事项和限制，开发者将能够更好地利用小程序全局工具栏功能，提升用户体验和操作便利性。 案例展示我们通过实际案例来介绍小程序全局工具栏的应用场景～ 以微信学堂为例，我们可以使用全局工具栏来实现课程播放栏的功能。在课程播放的过程中，我们可以浏览其他课程、查看课程介绍等等。在这种情况下，实现一个全局的课程播放栏可以很好地提升用户体验。借助小程序全局工具栏，我们可以轻松实现这一功能～ [图片] 接下来，让我们来看看具体的代码实现～ 使用十分简单，我们参照使用步骤建立 app-bar 组件，然后我们只需要在 app-bar 组件中实现我们的业务代码即可。 我们的课程播放器还结合了手势和 worklet 动画，实现了最小化和最大化全局工具栏的效果，用户可以根据自己的需要来切换全局工具栏的大小，提高用户使用体验，实现更加丰富和高效的用户界面～ 在 app-bar/index.wxml 中，实现的代码与我们平时写自定义组件无异，可以根据业务诉求实现自定义的组件，我们这里展示了课程播放器的实现。 <!-- app-bar/index.wxml --> <vertical-drag-gesture-handler worklet:ongesture="handleVerticalDrag"> <view class="expand-container"> <!-- 最大化展示：nav-bar --> <view class="nav-bar column"></view> <!-- 跟着手势变化，改变组件的展示效果 --> <view class="cover-area" style="height: {{maxCoverSize}}px;"> <view class="row " bind:tap="expand">               <!-- 跟着手势改变宽高 --> <image class="cover" mode="aspectFill" src="{{musicCover}}" />                              <!-- 最小化展示：标题、按钮 --> <view class="title-wrap row-between"> <view class="title column"> <text overflow="ellipsis" max-lines="1">Skyline 渲染框架入门与实践</text> <text class="name" overflow="ellipsis" max-lines="1">小程序技术专员 - binnie</text> </view> <view class="row"> <image class="icon" style="margin-right: 24px;" src="/assets/play.png" /> <image class="icon" src="/assets/next.png" /> </view> </view> </view> </view> <!-- 最大化展示：详情内容 --> <view class="music-title">...</view> <view class="footer">...</view>        </view> </vertical-drag-gesture-handler> 因为我们在 wxml 中使用了手势系统，所以我们需要给手势加上手势事件，这样我们就实现了一个顺滑的课程播放器啦～ 如果你还没有学习过 worklet 动画和手势系统，建议可以学习一下 worklet 动画 和 手势系统，了解之后你将更好地理解我们在课程播放器中使用的手势和 worklet 动画的实现方式，同时，worklet 动画和手势系统也可以帮助你实现更加复杂和丰富的用户界面。 Component({   lifetimes: {     attached() {       const progress = shared(0)       // 通过 worklet 改变各个组件的状态       this.applyAnimatedStyle('.cover', () => {         'worklet'         ...       })       this.applyAnimatedStyle('.expand-container', () => {         'worklet'         ...       })       this.applyAnimatedStyle('.title-wrap', () => {         'worklet'         return {           opacity: 1 - progress.value         }       })       this.applyAnimatedStyle('.nav-bar', () => {         'worklet'         ...       })       this.progress = progress     }   },   methods: {   // vertical-drag-gesture-handler 绑定的手势事件     handleVerticalDrag(evt) {       'worklet'       if (evt.state === GestureState.ACTIVE) {         const delta = evt.deltaY / screenHeight         this.handleDragUpdate(delta)       } else if (evt.state === GestureState.END) {         const velocity = evt.velocityY / screenHeight         this.handleDragEnd(velocity)       } else if (evt.state === GestureState.CANCELLED) {         this.handleDragEnd(0.0)       }     },     // 手势变化时     handleDragUpdate(delta) {       'worklet'       const curValue = this.progress.value       const newVal = curValue - delta       this.progress.value = clamp(newVal, 0.0, 1.0)     },     // 手势结束时     handleDragEnd(velocity) {       'worklet'       ...       if (animateForward) {         this.progress.value = timing(           1.0, {           duration: 200,           easing: animationCurve,         })       }       ...     }   } }) 以上是我们实现课程播放器的核心代码，如果您想要进一步了解和实践，可在 PC 端点击 代码片段 进行调试。 总结小程序全局工具栏为用户提供了更加便捷的操作方式和更丰富的功能，让小程序的使用体验得到了显著提升。通过全局工具栏，用户可以在不同页面间快速切换，轻松访问常用功能，同时还可以自定义工具栏，满足个性化需求。此外，全局工具栏还可以帮助开发者提高用户粘性，提升小程序的活跃度。 小程序全局工具栏适用于多种场景，如电商平台、在线教育、新闻资讯、工具类等。例如，电商平台可以将购物车、订单等入口放置在全局工具栏上，方便用户随时查看和管理；在线教育平台可以将课程列表、学习记录等功能放置在全局工具栏上，方便用户快速找到所需内容。 小程序全局工具栏是一个非常实用的功能，可以帮助用户更好地使用小程序，同时也为开发者提供了提升用户体验和增加用户粘性的机会。我们邀请大家尝试将小程序全局工具栏这个能力应用到自己的小程序上，为用户带来更好的使用体验～

最近受平台规范监管影响，关于部分自营交易小程序受到无法绑定和正常使用云开发微信支付，本文详细介绍相关解决方案思路。 引用 Memory的社区回答： 根据2022年12月25号更新的「交易类小程序运营规范」，适用于符合如下一种或多种情形的小程序： 1.1、 小程序内提供珠宝玉石、3C数码等商品在线销售及配送服务； 1.2、 小程序的账号主体为近一年内新成立的企业或个体户主体； 1.3、 小程序的账号管理员、运营者等角色，与其它高风险小程序存在关联 ； 1.4、 小程序内经营预售商品。 如符合以上情况的，需在用户主动/系统自动确认收货后（在用户点击“确认收货”、或商家录入发货信息后达到系统自动确认收货的时间周期），进行资金结算。 目前银行、支付机构、渠道商、普通服务商及从业机构特约商户五类商户暂不支持接入及授权，所以商家自营的小程序暂不支持和上述类型的商户号关联。 云开发原微信支付走的是授权特殊服务商，命中上面规则就不能走服务商模式了，所以无法绑定。 一、影响判断和后台操作关于如何判断是否受影响，以及受影响后具体的操作步骤可以参考此指南： 一文教你处理“受平台方要求暂时冻结资金"问题 其中关于微信支付接口的对接需要单独开发，对于原云开发微信支付使用开发者来说，独立开发门槛如果太高，可以直接使用云开发最新的工作流解决这个问题，接下来具体的介绍相关的操作步骤 二、使用工作流完成微信支付对接目前云开发推出专门用来接入微信支付的云模板，可以直接使用，详情参考： 微信开放文档｜微信云开发云模板-微信支付模板 微信学堂｜微信支付模板课程 工作流是云开发推出的服务端业务逻辑的可视化编排工具，帮助开发者更清晰、灵活、高效地组织和管理业务逻辑。 具体的流程图如下： [图片] 详细操作步骤请参考此系列文档： 工作流实现微信支付付款、接收事件回调工作流实现微信支付退款场景 三、总结除了上述微信支付相关支持外，工作流还能做更多，比如： 公众号的普通消息监听 和 事件推送小程序的客服消息与事件监听 和 发货信息管理服务消息 工作流主要有以下特性： 可视化：开发者通过拖拉拽方式以及简单的节点完成配置与调试，快速开发业务流程，使其更直观和易于理解，同时便于团队成员之间沟通和协作；可扩展：工作流提供基于云函数的脚本节点，支持用自定义代码实现复杂逻辑，满足各种不同的业务场景和需求。 如果你在使用中有任何疑点或者寻求方案，可以联系微信云服务的架构师。  关于本文中提出的观点和内容，如果你有其他补充和意见，欢迎在文章下留言～

一、写在前面 我比较喜欢做微信生态的解决方案，给企业或个人提供一些技术方案和应用形态选型的咨询。最近跟一些朋友聊天，他们在各自的工作岗位中，随着工作熟悉就会自然而然有很多能提升工作效率的点子。 有些人喜欢用文档、问卷、表单等 SAAS 应用捏合一个自己的效率集，一般能满足很多场景；但还有一些场景可能没有合适的 SAAS 应用，于是就想搞个小程序，然后来问我怎么做比较合适。 “小程序一定程度上降低了开发者搭建应用的门槛，做一个小程序相比其他的产品形态效率更高，落地更快。”，这个观念在这几年的发展中越来越深入，有很多不是软件行业的朋友都能提出小程序这种想法。 通过简单的代码，做一个满足自身小场景的小程序，并不是很难。有一定的数理基础，配合社区的入门教程很容易上手。上手门槛已经降低到中小学生都能触及到的程度了，微信还针对的搞了个少年挑战赛。 完整的闭环一个应用，单纯用小程序做个前台还是不够的，很多情况下我们需要有后台做管理支撑。 比如一个登记小程序，除了小程序能够提供登记信息填写外，还需要一个后台能够承载管理人员做状态扭转或者其他的后备工作。 一般这种情况下有几种解决思路： 1.  在小程序中编写管理页面，通过用户 openid 来指定仅管理员可见。 2.  通过接口对接企业微信或者其他 SAAS 平台的 webhook 能力来组合管理。 3.  搭建一个可操作的管理后台，有细粒度的权限管控。 接下来我主要分析一下这几种方式的实现和利弊，你可以根据自身的需要有针对的选型。 二、后台方案对比 1.  在小程序中编写管理页面，通过用户 openid 来指定仅管理员可见。 实现方式：编写单独的管理页面，或者在业务页面中嵌入一些管理按钮，每次加载时，通过后端比对 openid 返回给小程序端是否可以展示管理页面或内容。方案优势：小程序开发难度，低门槛，实现简单。方案劣势：管理权限的授予以及可靠性维护太差，浪费资源。 ○ 管理者的身份需要设计机制去确认（手机号关联or访问记录） ○ 管理页和内容占用小程序包资源，影响普通用户的使用体验 ○ 正常用户访问也会判断管理员逻辑，浪费数据库读资源（硬编码则维护难度增大） ○ 管理接口与业务接口有混用的风险 [图片] 这种实现是大部分初入者首选的，因为微信用户体系比较完备，可以通过 openid 来确定一个微信用户。在用户打开小程序时，服务端判断用户身份是否是管理员，如果是的话返回一些信息给小程序，小程序对应的展示相关管理页面内容或入口。 劣势也是非常明显的，由于管理逻辑与业务逻辑都集中在小程序通信，会在身份判断，业务处理上有更多的无效的数据库读请求，浪费资源。 [图片] 2.  通过接口对接企业微信或者其他 SAAS 平台的 webhook 能力来组合管理。 实现方式：暴露一些接口，然后使用企业微信的机器人或其他工具对接暴露的接口，实现通过消息或者点击驱动接口完成一些配置。比如访问接口地址填写一些特定参数来实现状态扭转（https://www.example.com/api/status?id=10001&type=success&key=1212）方案优势：只需要提供接口即可，几乎没有前端的开发成本。方案劣势：可读性比较差，并且有被攻击的风险，接口安全需要下功夫。 ○ 可读性比较差，无法可视化，但可通过其他工具加以改善。 ○ 由接口的参数驱动，权限校验为明码，容易泄露。 ○ 应对管理场景有限，无法应用到复杂的管理操作（如上传图像或批量处理） [图片] 这种方案一般用于非常简单的管理场景中，比如就只针对一个事项做状态扭转，发起一个批处理的任务，发送通知等。完全由接口来驱动完成。但权限管控只能通过参数来明码输入，或者通过结合 saas 工具，来利用其调用时的 header 信息来做权限判断。 [图片] 3.  搭建一个可操作的管理后台，有细粒度的权限管控。 实现方式：搭建独立的 WEB 后台（或APP ），来统一设计用户管理权限，以及搭建各种业务的管理流程。尽量不在接口层面与业务端有交集，仅做数据层面的处理和互通。方案优势：灵活度大，可以实现任意后台管理场景，并且可以接入丰富的权限管控。方案劣势：搭建难度大，处理的开发流程复杂，可能需要重新设计一套用户体系。 ○ 搭建难度可能远远超过小程序前台，需要考虑投入是否值得。 ○ 根据所需可能要对接不同的用户登录体系，比如用户名密码+微信登录+邮件登录。 [图片] 这是一个标准的方案，业务后台页面的构成和功能设计需要根据自己的业务场景来单独设计，其用户群体为业务管理者。在功能实现上既可以有数据库的增删改查，也可以有外部平台的调用（比如微信支付分账，发起退款，发送邮件通知等）。作为开发者在搭建后台时，遇到的实现点和难度可能都是高门槛的，所以需要一定的技术积累，并充分理解用户群体（业务管理员）的工作流程。 [图片] 三、微信在后台方面做了什么？ 为了让开发者在做个小程序这方面的门槛降低，从设备端到用户体系，从单机存储到联网同步。微信团队围绕小程序开发的各个环节提供了很多产品和服务形态，其核心目标就是让开发者做小程序的门槛变得更低。 比如微信云服务，Donut 开发平台，通过提供云端资源和平台能力，在一些方面多做一些，让开发者少做一些。 在业务后台这个方面，实现上脱离小程序本体，但是从业务经营者角度来看，又是小程序业务不可或缺的一环。所以微信针对业务后台这方面也提供了解决方案： 云后台是微信最近上线的一个能力，主要面向小程序或公众号 H5 场景的业务开发者，沉淀常见的后台管理场景；通过提供丰富应用模板、开放数据接口、灵活管理权限等功能，降低开发者搭建后台的成本，提升开发效率。 [图片] 通俗来解释的话主要就有 3 个亮点： 1.  丰富的模板应用和灵活的搭建驱动。 除了我们常需要的 CMS 内容管理，还提供常见的商品管理，订单管理，数据分析，支付管理等等。如果这些模板不能满足你的场景或者场景没覆盖全，你可以直接去编辑应用，用低代码编辑器来搭建自己心目中的理想应用。[图片] 2.  可以自由定义的数据接口和外部平台连接 云后台自动携带一个中心化数据源，并提供完备的数据操作接口。如果你自己有自建的数据源，可以在云后台自由配置连接，直接对接到各个后台应用提供针对微信开放平台、微信支付平台的现成连接接口，只需要配置令牌信息就可以直接用，不需要花时间再做调试。[图片] 3.  提供灵活的用户权限管理，细粒度控制 云后台内置用户权限体系，可以针对不同业务管理场景创建角色，并赋予特定的应用可见和可操作权限。提供丰富的认证源，比如微信扫码登录，或者自建的认证源。[图片] [图片] 其中我觉得对初学者友好的一点是，如果你只开发了一个单机小程序，还没有做云端接入。云后台由于有中心化数据源，也就意味着你不需要自己搭建后端服务了，直接使用云后台暴露出来的接口调用就好。 [图片] [图片] 有关于云后台的具体使用细节的动态体验，我会在后面单独开一篇文章，发布后会更新到这里，如果感兴趣可以关注下。 四、总结 如果你目前正在为业务后台的搭建烦恼，或者有计划升级你的后台形式，不妨可以花点时间体验一下，具体请参见云后台文档。 如果你有小程序前后端开发的疑点或者寻求方案，可以联系微信云服务的架构师。 关于本文中提出的观点和内容，如果你有其他补充和意见，欢迎在文章下留言一起探讨～

获取手机号组件如何选择套餐，怎么选择呢？ [图片] 请广大开发者，根据自己的额度选择最佳效率的。 比如我的小程序每月2.4w，综合下来选择最优先考虑的不是单价是合适的月份消耗（仅供参考）。我会选择以下几个套餐来充值。 [图片] [图片] 以下表格针对个人开发者参考（如需要原表格建议请评论区联系） 价格优惠排序版本 [图片] 时间排序版本 [图片] 针对服务商部分建议关注帖子。作者会在收到套餐后更新/

你是否也收到这样的用户反馈？ 商品列表滚动区域太小，很难找到想要的商品。头部的搜索广告占据了半个屏幕，挤占了实际空间。在我手机这样小的屏幕上，展示区域太小了，能否把它放大点？[图片] 在电商页面中，我们需要向用户展示众多的商品、广告等信息。 然而，如何在有限的屏幕空间中更好地展示它们，是一个需要我们深入思考的问题。 由于小程序 webview 渲染框架在技术存在一定的局限性，我们需要在不同的设计之间进行抉择。 当广告具有较高的优先级时，我们会考虑突出广告的展示，同时减小商品列表在界面中所占比例。当商品列表具有较高的优先级时，我们会考虑优先展示商品，而放弃广告的展示。[图片] 但是当广告和商品列表同样重要的情况下，要怎么办呢？ 常见的一种设计方式是设计一个隐藏按钮，当用户不想看广告的时候把广告隐藏掉，隐藏之后商品列表就有更多展示空间 [图片] 但是这种情况也只是针对愿意手动点击隐藏按钮的情况下，还是有一定的局限性。 那么，有没有办法做到在无形中隐藏广告呢？ [图片] 说到这里，当然是可以的啦✌️ 1、吸顶布局 + worklet 轻松实现 在常见的电商小程序首页，通常是顶部展示类目、接着展示商品详情，商品详情顶部也有热门等等的分类。 当页面滚动的时候，我们希望商品详情热门分类可以吸在顶部，便于切换。 [图片] 这里我们用到了 scroll-view 的 sticky-header、sticky-section 吸顶布局容器即可轻松实现。 ... ... ... 当 scroll-view 滚动的时候，根据滚动位置把搜索框放到标题的位置，可以再节省一点空间 attached() { // nav-bar 隐藏或展示 this.applyAnimatedStyle('.nav-bar', () => { 'worklet' return { opacity: this.navBarOpactiy.value } }) // 改变搜索框宽度 this.applyAnimatedStyle('.search', () => { 'worklet' return { width: `${this.searchBarWidth.value}%`, } }) }, // scroll-view 监听函数 handleScrollUpdate(evt) { 'worklet' const maxDistance = 60 const scrollTop = clamp(evt.detail.scrollTop, 0, maxDistance) const progress = scrollTop / maxDistance const EasingFn = Easing.cubicBezier(0.4, 0.0, 0.2, 1.0) this.searchBarWidth.value = lerp(100, 70, EasingFn(progress)) this.navBarOpactiy.value = lerp(1, 0, progress) }, 2、手势 + worklet 操作更灵活 小程序新渲染框架支持了手势系统，手势在这里可以发挥大作用～ 我们可以使用手势协商让小程序页面中的广告、商品等无缝切换和更好的展示 [图片] // .wxml           ...         // .js handlePan(e) {       'worklet'       ...       if (e.state === GestureState.ACTIVE) {         if (this._interactionState.value === InteractionState.UNFOLD) {           // 展开状态下，往上滑才折叠起来           if (e.absoluteY - this._startY.value < 0) {             this._interactionState.value = InteractionState.ANIMATING             this._translY.value = timing(0.0, { duration: 250 }, () => {               'worklet'               this._interactionState.value = InteractionState.RESET             })           }         } else {           // 其它情况，跟随手指滑动           this._translY.value = e.absoluteY - this._startY.value         }       }       // 其他状态下的处理   ... }, 加入手势之后，除了可以隐藏广告，我们还可以将一些头部信息隐藏 在用户查看商品列表时，隐藏大部分无用信息，将商品列表展示区域最大化 // 最外层 .page 往上挪 this.applyAnimatedStyle('.page', () => { 'worklet' const translY = clamp(this._translY.value, -this._tabsTop.value, 0) return { transform: `translateY(${translY}px)` } }) // 改变 .navigation-bar 背景色 this.applyAnimatedStyle('.navigation-bar', () => { 'worklet' const translY = clamp(this._translY.value, -this._tabsTop.value, 0) const opacity = translY / -this._tabsTop.value return { backgroundColor: `rgba(255, 255, 255, ${opacity})` } }) // 输入框：改变宽度并且展示 this.applyAnimatedStyle('.search-input', () => { 'worklet' const translY = clamp(this._translY.value, -this._tabsTop.value, 0) const percentage = translY / -this._tabsTop.value return { width: `${percentage * 60 + 40}%`, opacity: percentage, } }) 除此之外，我们这里可以利用手势来展示商家的一些信息 当在商品列表往下拉到顶部时，触发整个列表下拉展示出商家信息 再往上滑动则商品列表重新展示～ [图片] // 商品详情往下拉 this.applyAnimatedStyle('.main', () => { 'worklet' const translY = clamp(this._translY.value, 0, Number.MAX_VALUE) console.log(222, translY) return { transform: `translateY(${translY}px)` } }) // 简单的 header 渐隐 // 商品详情展示时，仅显示简单的 header：学堂名称和几个标签 this.applyAnimatedStyle('.header-shop-info-simple', () => { 'worklet' const min = 50 const max = 100 const translY = clamp(this._translY.value, min, max) - min return { opacity: 1 - (translY / (max - min)) } }) // 复杂的 header 渐显 // 商品详情下拉，显示复杂 header：展示热门活动、公告等等信息 this.applyAnimatedStyle('.header-shop-info-detail', () => { 'worklet' const min = 100 const max = 150 const translY = clamp(this._translY.value, min, max) - min return { opacity: translY / (max - min) } }) 加入手势动画之后，我们的页面展示对比之前有了以下的优势： 更加自然：更符合用户操作习惯，用户自然滚动屏幕时不会感到突兀更节省空间：滚动隐藏更为灵活、省空间，使页面更清爽更高效的展示：可以将要展示的内容更好的展示，无需做取舍 借助手势动画，我们可以优化小程序界面展示、提升用户体验，从而获得更高的商业价值。 如果你也想更好的留住用户，mark 下这个 源码 [ 瀑布流页面 / 分类页面 ] 直接接到到你的小程序吧～

在上一篇文章《在小程序中实现原生相册》中，我们学习了自定义路由搭配共享元素实现的原生相册效果，共享元素可以让用户在体验小程序时视觉关联性更强。 除了相册实现之外，常见的卡片转场也非常适合。 [图片] ⬆️ 演示效果：默认动画 vs 卡片转场动画 👇 下面我们来看看卡片转场中通过 共享元素 + 自定义路由 来实现无痕跳转。 [图片] 这里的转场稍微有点复杂，涉及到以下 3 个点 旧卡片：图片放大、内容渐隐新页面：按比例放大、页面渐显手势搭配1、旧卡片：图片放大、内容渐隐 在本示例中，列表页采用的是 scroll-view 瀑布流布局的实现。 [图片] 这里我们的共享元素是卡片，即 grid-view 中的内容 card，卡片包括 图片、内容描述。 [图片] 默认情况下，共享元素是整个节点进行飞跃的，由于前后页面的图片元素一致但文本内容不一致， 导致在第一帧或者最后一帧会有跳动的效果。 为了让转场动画更加自然，我们需要在飞跃的过程中渐隐旧卡片的内容描述。 [图片] 在这里，我们需要先用 this.applyAnimatedStyle 来给对应的节点绑定 worklet 驱动动画。 .card_wrap 节点：整个卡片按比例放大.card_desc 节点：内容描述渐隐[图片] 关于动画执行的时机，我们可以通过配置项修改。 immediate：设置是否立即执行驱动动画flush：shareValue 更新时，applyAnimatedStyle 的 updater 函数刷新时机在本例中，需要保证共享元素的图片与目标页面图片位置重叠，所以 flush 设置 sync 在当前时间片刷新。 [图片] 绑定完驱动动画之后，我们需要给共享元素绑定帧回调事件，根据当前动画进度改变共享变量的值来驱动共享动画 [图片] 2、新页面：按比例放大、页面渐显 新页面在路由中的动画，需要在自定义路由中进行配置。关于自定义路由的更多介绍，可参考《小程序页面转场动画》 在路由动画过程中，我们将上一步的共享元素帧回调拿到 begin、end 的值，然后结合动画进度 t 计算得出新页面的位置、缩放比例。 还有根据动画进度，设置页面渐显，与前面的卡片渐隐承接。 [图片] 3、手势搭配 学习过我们前面的文章的同学都知道，自定义路由经常需要结合页面手势，来实现手势返回，关于手势的基础知识可参考《小程序页面转场动画》 [图片] 这里我们希望手势缩小整个当前页面，所以这里手势返回时只在当前页面做手势动画即可。 在页面详情页的最外层，嵌套一个手势组件 pan-gesture-handler，当手势拖动时根据手势的位置改变整个页面（通过 #fake-host 控制）的位置和大小来达到拖动的效果。 [图片] 同样绑定页面驱动动画，通过 applyAnimatedStyle 给 #fake-host 绑定驱动动画，当共享变量 transX、transY 等变化时则自动改变 transform 来驱动 #fake-host 缩小。 [图片] 接着绑定手势事件，根据手势拖动时拿到位置信息改变共享变量 transX、transY 的值。 [图片] 最后我们需要设置背景颜色透明，来达到类似把卡片拖回列表的视觉效果，更好的减少页面切换感～ [图片] 一个自定义路由的页面会有 3 层可以设置到背景色，要做到透明的效果需要将 3 个背景色都设置为透明。更多自定义路由背景色的详情参考官方文档。 [图片] 想要试试卡片转场的无恒效果～扫描 ⬇️ 下方小程序码即可体验。 如果你也想在小程序中实现卡片转场动画，mark 下这个 源码 直接接到到你的小程序吧～ [图片]

相册在日常生活中经常使用到，如手机自带相册、朋友圈、商品展示图、评论贴图等等，都经常用到相册的能力。 👇下面演示 iOS 原生相册、朋友圈等相册使用效果，我们可以看到图片切换非常顺滑，视觉焦点不变。 [图片] 😭 但是在小程序中，页面切换会有明显的切换感。用户焦点会丢失，缺少视觉关联性。 [图片] 共享元素🔥 为了丰富用户交互效果、提升用户体验、增强视觉关联性，小程序支持了页面间的共享元素 下图展示有无共享元素的页面切换效果，可以看出使用共享元素之后，转场动画更灵活 [图片] 共享元素 经常作用在图片上，例如上面示例中的相册效果，是那么共享元素动画要怎么实现呢？ 在页面跳转时，两个页面 key 相同的 share-element 组件则会产生飞跃的过渡效果 [图片] 在上一篇文章中，我们学习了 页面转场动画，共享元素动画跟页面转场动画是类似的，同样是在页面切换间的动画。 动画进度、时间 与 路由进度、时间保持一致（非自定义路由也支持共享元素动画） 在共享元素飞跃的过程中，前后页面图片的裁剪方式（mode） 可能不一致 这种情况下容易导致图片突然跳变，所以我们需要在飞跃的过程中改变图片的大小来保证平滑飞跃 [图片] 在共享元素动画进行的过程中，share-element 可以收到 onFrame 表示动画帧回调 我们可以在帧回调中处理内部元素的显示 例如：我们这里通过在帧回调中改变图片宽高来达到平滑飞跃的效果 // .wxml   // .js // 初始化 attached() {    this.aspectRatio = shared(0)   this.curRect = shared(undefined)   // 绑定 worklet 动画   this.applyAnimatedStyle('.img', () => {     'worklet'     const curRect = this.curRect.value     return {       left: `${curRect.left}px`,       top: `${curRect.top}px`,       width: `${curRect.width}px`,       height: `${curRect.height}px`     }   }) }, // 获取图片初始宽高比 onImageLoad(e) {   const { width, height } = e.detail   this.aspectRatio.value = width / height }, // 动画帧回调，调整图片大小 onFrame(data) {   'worklet'   // 当前帧容器的宽高、进度等信息   const { begin, end, progress, direction } = data      ...   // 根据图片初始宽高比、共享元素容器、动画进度等计算出变化过程中的值   this.curRect.value = {     left = lerp(begin.left, end.left, t),     top = lerp(begin.top, end.top, t),     width = lerp(begin.width, end.width, t),     height = lerp(begin.height, end.height, t),   } } 更多共享元素动画原理请查看 官方文档 手势搭配打开图片之后，我们经常需要用到手势来操作图片，如缩放、移动、双击等等 [图片] 我们上次学过的 手势系统 又派上用场啦 通过监听手势事件配合 worklet 函数即可在小程序实现图片预览效果 👇 下面演示缩放手势的处理，除了缩放之外，相册在手势处理上还有很多复杂的逻辑，包括惯性、边界逻辑判断等 点击查看更多相册相关的手势操作 // .wxml // 绑定缩放手势         let sharedValues = this.sharedValues ?? [] // .js // 绑定缩放 this.applyAnimatedStyle('#image', () => {   'worklet'   // worklet 函数，sharedValues 变化时，函数会立即执行   return {     transform: `scale(${sharedValues[SCALE].value})`   } }) // 监听缩放 onScale(evt) {   'worklet'      // 连续的手势状态 && 双指放缩   if (evt.state === GestureState.ACTIVE && evt.pointerCount === 2) { // 计算出当前真正的缩放值 sharedValues[SCALE].value = evt.scale / sharedValues[TEMP_LAST_SCALE].value sharedValues[TEMP_LAST_SCALE].value = evt.scale   } } 最后，我们来看下小程序实现出来的相册跟原生相册的使用对比，在小程序也可以顺滑的实现类原生的效果啦～ [图片] 目前，同程旅行 已经上线了共享元素结合手势的相册效果，mark这个 相册源码 直接接入到你的小程序吧～ [视频]

在小程序页面开发中，我们经常用半屏弹窗来进来内容展示，例如：微信开放社区切换主页、加入购物车的选项页、文章留言区等等。 [图片] 常见的半屏弹窗展示逻辑是这样的： 打开弹窗：点击 “打开弹窗” 按钮展示弹窗关闭弹窗：点击“关闭按钮” or 遮罩层 关闭弹窗当我们想在半屏弹窗加一些交互动画时，可以监听节点的 touch 事件来做一些手势判断，进而处理拖拽事件。但是这种方式实现的滚动动画容易卡顿，出现延迟的情况，效果并不理想。 为了丰富小程序的交互体验，我们内置了一批手势组件，可以帮助开发者更好的实现交互动画的效果。 下图演示使用手势的半屏弹窗下拉效果与普通半屏下拉的对比。 当内部评论列表往下拉到顶部时，变为半屏的下拉，可直接下拉关闭弹窗。 [图片] 我们来看下这种操作是怎么实现的 在上面评论列表的半屏弹窗中会有一个 scroll-view 滚动组件，在 scroll-view 中会有滚动事件，当滚动到顶部时，我们希望有整个半屏的下拉事件。 所以我们需要在半屏的最外层放置一个拖动手势组件 pan-gesture-handler 由于拖动组件内部的 scroll-view 也是可以滚动的，所以这里需要进行一个手势协商的处理，就是什么条件下由哪个组件来响应手势。 当手势往下 ⬇️ 滚动时，此时判断内部 scroll-view 滚动条的位置 滚动条处于顶部：外层 pan-gesture-handler 响应滚动，此时半屏往下拖动至关闭半屏滚动条不处于顶部：内层 scroll-view 响应滚动，此时内部列表往上滚[图片] 当手势往上 ⬆️ 滚动时，此时判断半屏的位置 半屏不完全打开时：外层 pan-gesture-handler 响应滚动，此时半屏往上拖动至完全打开半屏半屏完全打开时：内层 scroll-view 响应滚动，此时内部列表往下滚[图片] 我们来看一下代码的实现，这里用到的手势组件 pan-gesture-handler（拖动时触发）和  vertical-drag-gesture-handler（纵向滑动时触发），手势组件有以下属性 on-gesture-event：手势回调事件should-response-on-move：是否响应当前手势的 move 阶段simultaneous-handlers：指定需要协商的手势是哪几个，下面演示表示 pan 和 scroll 协同触发。native-view：代理的原生节点，这里 scroll-view（scroll-y） 内有个 vertical-drag 手势，scroll-view 自身无法处理，需要被代理出来         ...   接着，我们看看在页面 js 中怎么处理手势。 在手势处理的回调中因为会改变半屏的状态值，所以这里的回调函数采用 worklet 函数，worklet 函数运行在 UI 线程，使得小程序可以做到类原生动画般的体验。 // page.js // shared 创建的变量为共享变量，可在 UI 线程和 JS 线程间同步 this.transY = wx.worklet.shared(1000) this.scrollTop = wx.worklet.shared(0) this.startPan = wx.worklet.shared(true) // shouldPanResponse 和 shouldScrollViewResponse 用于 pan 手势和 scroll-view 滚动手势的协商 shouldPanResponse() {   'worklet'   return this.startPan.value }, shouldScrollViewResponse(pointerEvent) {   'worklet'   // transY > 0 说明 pan 手势在移动半屏，此时 scroll-view 滚动不应生效   if (this.transY.value > 0) return false   const scrollTop = this.scrollTop.value   const { deltaY } = pointerEvent   // deltaY > 0 是往上滚动，scrollTop <= 0 是滚动到顶部边界，此时 pan 开始生效，scroll-view 滚动不生效   const result = scrollTop <= 0 && deltaY > 0   this.startPan.value = result   return !result }, // pan 手势处理 handlePan(gestureEvent) {   'worklet'   if (gestureEvent.state === GestureState.ACTIVE) {     const curPosition = this.transY.value     const destination = Math.max(0, curPosition + gestureEvent.deltaY) // 改变半屏的位置     this.transY.value = destination   }   // 其他手势状态的处理，如滚动结束时计算半屏处于打开还是关闭的状态 } 目前，同程旅行 已经上线了手势结合半屏的效果 体验路径：酒店查询 - 选择酒店 - 选择入住人 - 新增入住人 [图片] 普通半屏结合手势代码片段：https://developers.weixin.qq.com/s/lx0RH1mD7rGj 手势除了在普通半屏的应用之外，也可以实现分段式半屏。下面演示的分段式半屏比普通半屏的判断条件更多一些。 判断条件同普通半屏类似，根据手势方向 和 分段式半屏当前的位置来判断是响应分段式半屏还是内部列表，响应分段式半屏是改变到哪一个位置。 [图片] 这里与普通半屏不同的是我们还改变了地图的缩放级别（scale） 因为 worklet 函数是在 UI 线程运行的，当要改变 data 值时，需要通过 wx.worklet.runOnJS 调回 JS 线程。 // page.js // 设置 map scale // 运行在 JS 线程 setMapScale(scale) {   this.setData({ scale }) }, // worklet 函数，运行在 UI 线程 scrollTo(toValue) {   'worklet'   let scale = 18   if (toValue > screenHeight / 2) {     scale = 16   }   // 从 UI 线程调回 JS 线程   wx.worklet.runOnJS(this.setMapScale.bind(this))(scale)   this.transY.value = timing(toValue, { duration: 200 }) }, // 处理拖动半屏的手势 handlePan(gestureEvent) {   'worklet'   // 滚动半屏的位置   if (gestureEvent.state === GestureState.ACTIVE) {     // deltaY < 0，往上滑动     this.upward.value = gestureEvent.deltaY < 0     // 当前半屏位置     const curPosition = this.transY.value     // 只能在 [statusBarHeight, screenHeight] 之间移动     const destination = clamp(curPosition + gestureEvent.deltaY, statusBarHeight, screenHeight)     if (curPosition === destination) return     // 改变 transY，来改变半屏的位置     this.transY.value = destination   }   if (gestureEvent.state === GestureState.END || gestureEvent.state === GestureState.CANCELLED) {     if (this.transY.value <= screenHeight / 2) {       // 在上面的位置       if (this.upward.value) {         this.scrollTo(statusBarHeight)       } else {         this.scrollTo(screenHeight / 2)       }     } else if (this.transY.value > screenHeight / 2 && this.transY.value <= this.initTransY.value) {       // 在中间位置的时候       if (this.upward.value) {         this.scrollTo(screenHeight / 2)       } else {         this.scrollTo(this.initTransY.value)       }     } else {       // 在最下面的位置       this.scrollTo(this.initTransY.value)     }   } }, 分段式页面代码片段：https://developers.weixin.qq.com/s/fw0U31mI7bGf 半屏的交互除了在页面内实现，也能跨页面实现，如常见的下沉式半屏交互。其中，半屏效果与上述实现类似，而前一页面的下沉实现需要结合自定义路由 后面的文章中我们会介绍自定义路由结合手势怎么去实现下沉式半屏效果，不仅如此，还有很多类原生的页面切换效果都能通过自定义路由实现 [图片]

在之前的文章中，我们知道了新 scroll-view 可以让小程序的长列表做到丝滑滚动～ 也提到了新 scroll-view 提供了很多新能力 sticky、网格布局、瀑布流布局等，这一篇，我们就来看看这些新能力是怎么使用的～ 新 scroll-view 在原来列表模式（type="list"）的基础上，新增了自定义模式（type="custom"） 在自定义模式下，新增了以下新组件供开发者调用 list-view：列表布局容器sticky-section / sticky-header：吸顶布局容器grid-view：网格布局容器，可实现网格布局、瀑布流布局等sticky布局sticky 布局即在应用中常见的吸顶布局，与 CSS 中的 position: sticky 实现的效果一致，当组件在屏幕范围内时，会按照正常的布局排列，当组件滚出屏幕范围时，始终会固定在屏幕顶部。 常见的使用场景有：通讯录、账单列表、菜单列表等等。 与 position: sticky 不同的是，position: sticky 很难实现列表滚动需要的交错吸顶效果，而 sticky 组件则可以帮忙开发者轻松实现交错吸顶的效果。 sticky 的使用非常简单： 将 scroll-view 切换到 custom 模式采用 sticky-section 作为 scroll-view 的子元素sticky-header 放置吸顶内容list-view 放置列表内容             {{item.name}}               ...       我们来看下采用 sticky 布局做出来的通讯录效果～ [视频] sticky 布局也可以通过给 sticky-section 配置 push-pinned-header 来声明吸顶元素重叠时是否继续上推 像下图输入框和标签列表这种类型，标签列表吸顶时还是希望保留输入框吸顶。 [视频] 网格布局网格布局即将列表切割成格子，每一行的高度固定，常见的视频列表、照片列表等通常都采用网格布局。 在此之前，实现网格布局需要开发者自行实现网格切割，再嵌入到 scroll-view 中。 新 scroll-view 直接提供了 grid-view 组件供开发者使用～ 将 scroll-view 切换到 custom 模式采用 grid-view 类型为 aligned 做为直接子节点grid-view 中直接编写列表                   ...       下面是使用网格布局实现的图片列表效果～ [视频] 瀑布流布局瀑布流布局与网格布局类似，不同的是瀑布流布局中每个格子的高度都可以是不一致的，所以在小程序中实现瀑布流布局就比较复杂了。 开发者需要通过计算格子高度，然后再进行瀑布流拼接，当滚动内容过多时还需要处理节点过多导致内存不足等问题。 grid-view 组件直接支持了瀑布流模式供开发者直接使用，grid-view 组件会根据子元素高度自动布局： 将 scroll-view 切换到 custom 模式采用 grid-view 类型为 masonry 做为直接子节点grid-view 中直接编写列表                   ...       下面是使用瀑布流布局实现的图片列表效果～ [视频] 想要立即体验？现在通过微信开发者工具导入 代码片段，即可体验新版 scroll-view 组件能力～

一、  背景叙述 从公众号开始，小程序、移动应用、网站应用，到现在的视频号小店，微信提供很多种应用形态，让企业和个人开发者可以用适合的形式接入微信生态，满足自己的业务需求。 另外微信还提供第三方平台，为各行业的解决方案服务商提供了一个窗口，能够服务更多商家或中小企业个体接入微信生态，提升客户体验。 但无论是小程序、公众号还是第三方平台，依然只是在C端提供服务。无论是服务商还是企业个人开发者，想要通过上述形态接入微信生态，仍然离不开云端服务。 微信团队提供很优秀的开发和调试工具，单独做一个不联网的小程序，实现一些简单的功能，简单入门上手开发并不是很难。但如果是联网提供完整的带服务的小程序，对很多开发者来说就比较难了；更难的是另一个问：如何做一个稳定的、安全的后端服务？ 2018年，微信联合腾讯云推出云开发，主要解决的是小程序后端服务的高门槛问题。但提供的云函数对传统开发模式的改造成本太大，灵活度不是很高。于是在2020年推出微信云托管，提供通用的容器服务，将服务构建环节交给开发者。 无论是云开发和云托管，最关键的并不是提供一个后端服务，而是提供后端服务的安全访问。所以可以看到，无论是云开发还是云托管，在微信应用（小程序、公众号服务）中提供的callFunction、callContainer方法，相比request方法本质上是提供了一个安全的访问入口。 云开发、云托管在一定程度上承担了运维和部署环节，使得其非常容易入门，对新手开发者很友好。但并不是所有开发者都是新手，很多成熟的开发者都有自己的一套成熟后端服务。如果为了接入微信的安全访问，而直接迁移自己的服务到云开发或云托管，阻力是相当大的。 另外云开发、云托管提供的是可独立存在的后端云服务，有独立的数据存储，使得其在调用方上挣脱不开同主体的限制，这也是服务商开发者使用起来最为难受的点。 所以有没有一种方案，让开发者既可以使用自己熟悉的后端服务基座，又可以非常灵活方便的接入微信的安全访问？ 这就是新推出的Donut安全网关！ 二、  什么是安全网关，有什么特色？ Donut安全网关提供了一个安全的接入链路，从调用端（小程序、公众号H5、APP、WEB）发起的请求直接进入微信环境接入层，微信接入层通过中转域名将请求转发至后端服务网络的「网关实例」中，在「网关实例」中通过路由配置将请求转发到开发者自己的上游业务服务，完成整个请求。 [图片] 以上是整个链路的全景图，其中「网关实例」指的是部署在服务器或者是容器服务中的一套envoy网关（经过微信信息处理，有专属的证书加密）。 相比于云开发或云托管的访问链路，安全网关的链路是完全独立的，相对来说也更加成熟和安全。并且由于只做请求转发，不受同主体可用的限制。也就是说任何一个小程序或者公众号H5或其他形态应用，都可以使用安全网关链路实现请求。 当然，微信在链路中也提供了来源客户端的appid等标识，开发者可以在控制台或自己的后端服务针对的限制，防止其他未授权的客户端调用。 但是需要注意，安全网关并不是替代云开发或者云托管，安全网关可以与现在的云托管做深度融合，使得最终形态一定是对各类开发者均友好的。在云端服务领域还有很长的路程需要探索和精进！ 三、  开始配置安全网关 1.  登录注册Donut平台 访问Donut控制台，使用微信扫码登录。 [图片] 扫码完成后页面会自动跳转，进入控制台。首先先点击右上角头像，在列表中点击实名认证。 [图片] 填入自己的姓名和身份证号码后，会弹出如下二维码，使用微信客户端扫码验证。 [图片] 验证完成后会自动提示如下，此时就完成了实名认证流程。 [图片] 2.  开通安全网关 在控制台页面点击安全网关的「立即开通」按钮 [图片] 阅读服务协议并同意，开通完成！ [图片] 页面会自动刷新，点击上方菜单栏「安全网关」，显示下述页面，开通流程完成。 [图片] 3.  新建网关 在安全网关页面点击「新建网关」按钮，在弹出的对话框中填写网关名称，完成新建。一般网关以使用角度的应用维度区分，一般只需要一个即可，可以再创建一个用于规则测试。 [图片] 在这里我填写的是app，大家可以按自己想法来填。 4.  安装网关实例 网关实例是一个经过处理过的envoy网关，主要作用就是接收微信侧发过来的请求，并按照自己设置做路由分发等流量管理。所以网关实例运行的服务器或者容器服务，应该具备以下几个条件： 有公网接入：可以是带公网IP的服务器，也可以是任何一个公网访问的容器服务[比如TKE、云托管等]，如果服务器没有公网IP，可以在服务器的VPC网络中配置NAT网关，转发端口流量。尽量靠近业务后端服务：网关实例最重要的作用就是路由分发，分发的上游服务可以用内网IP访问，也可以用私有域名访问；不推荐使用公网再发出去，会增加请求耗时。所以尽量与业务后端服务处于同一个私有网络，如果跨地域了，可以考虑对等连接，或者在不同地域配置多个网关实例（用域名解析来实现就近接入）尽量避免与高峰值服务混在一起：虽然envoy本身对资源的消耗很小，但仍然需要注意不要与其他重资源消耗并可能引发宕机的服务部署在一起，否则将会导致网关实例不可用，从而影响请求顺利的转发。一般根据自身的情况，有很多种方案可以选择。选择好实例所在位置后，根据环境不同，参照控制台给出的详细步骤，安装实例。目前有如下几种： Docker：如果你的服务器安装有Docker，这是最方便的。将镜像直接下载下来运行即可。[图片] Linux：适用于大多数情况。有很多系统版本，注意自己的系统版本不要出错。安装过程基本就是开管理员权限进入终端，然后安装curl、wget、jq（基本都有，如果没有就搜索一下linux怎么安装XXX），剩下的就是直接复制一把运行，如果有出错，可以先搜索引擎一下解决，实在不知道怎么解决，可以评论下来看看[图片]  K8s：如果你的服务有运行于K8s运管的容器平台，可以用这个方法快速新建网关实例。最省心的方法！[图片] 在这里我使用一个服务器来执行安装过程，配置截图如下： [图片] 启动后进入root账号，执行命令如下：（最后一个是启动网关实例，可以使用nohup不挂断运行） [图片] 网关实例安装完毕后，控制台中点击「完成」按钮，进入下一步，可以在实例列表中看到已经安装在线的实例。 [图片] 注意：1. 在线情况下不可以从列表删除，需要先将网关下线，才可以从列表删除。2. 默认的对外端口为9903，但根据自己配置也会有所不同，注意打印的port内容。 5.  发布网关配置 网关配置主要分为两部分：上游服务、路由配置。我们来分别配置。 5.1 上游服务 上游服务就是请求最终到达的地方，一般可以称为业务服务地址。可以是域名，也可以是IP地址。 [图片] 在配置页点击「新建上游服务」按钮，弹出对话框，我们来填写一下。 [图片] 上游服务名称：路由配置时用它来区分，一般言简意赅的单词即可，比如login_server。备注：有时候英文不太容易记起具体是个什么，这里可以用中文长句描述一下给自己看。协议：有HTTP和HTTPS，一般内网就HTTP，节省耗时，外网或者有安全需要的HTTPS类型：分域名和IP，根据自己的情况来选择，一般选择IP。域名：内网可以用私有DNS解析来配置域名，公网可以正常填写。IP：类型为IP时可见，IP可以填写公网IP；同属一个私有网络可以填写内部IP；如果跟网关实例同属于一个服务器，则可以填127.0.0.1。在这里测试为了能让大家都能测试顺利并没有差异，直接填写一个mp官网的域名，后续可以根据自己的情况自己来变更。 注意：只在本测试中使用mp.weixin.qq.com，请不要在生产环境中尝试调用或恶意攻击操作。 [图片] 5.2 路由配置 配置完上游服务后，会提示配置路由，点击即可跳转至路由配置页面的对话框 [图片] 路由名称：清楚表示这个路由的作用即可，一般言简意赅的英文单词组合。上游服务：拉取当前配置的服务列表，以上游服务名称为索引。服务路径：就是访问时的路径，比如https://xx.com/api，想要匹配这个规则，路径就填写/api，如果没有路径就填 /路径改写-可选：目前只支持静态改写，就是将匹配的服务路径改写为指定的路径，再传递给上游服务。比如上面说的 /api 进来，可以改写成 /interface 传递给上游。请求限频-可选：配置这条路由的QPS值，流量防治的一种策略，默认是1000，范围是1-10000准入域名-可选：发过来的请求会匹配请求头中的host值；如果配置则只接受此host发来的请求，一般在接入层有多个时但需要区分流量时使用。在这里我们来配置一个测试用的路径，后面我们再配置更多来测试一下路由的能力。 [图片] 5.3 发布配置 在控制台中反复配置的路由和上游服务，并不会影响实际线上的网关实例。我们在配置完成后，需要点击控制台的「发布配置」按钮，将配置上传至网关实例。此时网关实例才能够应用我们的最新配置。 · [图片] 线上有了配置之后，我们就可以在右侧点击「线上网关配置」查看线上生效的配置情况 [图片] [图片] 6.  配置接入层 接入层是在微信侧的概念。网关接入层承接并转发业务流量，具备分布式安全防护能力，支持就近接入弱网加速，同时集成微信安全风控能力。 通俗来讲，就是客户端在访问网关时，需要有一个地址，而这个地址就是接入层的一个节点。微信对每一个接入节点创建了一个专门的地址，用来接收客户端流量。 接入节点一般以客户端应用区分（比如A应用APP、B小程序，C网页WEB），或者应用矩阵区分（A应用多端APP、小程序、WEB），这样可以随时阻断或者转移流量。另外可以通过路由配置的准入域名，来实现不同应用的差异化转发；服务商第三方平台也可以利用此特性，来实现普通客户的应用承载，以及VIP客户的应用承载分流。 只有一个接入节点的域名地址也没有用，还需要我们配置一下进入到这里的请求流量转发到哪里。 在控制台中，点击「接入层」的「新建接入节点」按钮。 [图片] 节点名称：一般以应用命名，言简意赅的英文单词组合即可。备注：可以详细描述一下服务的应用是哪些，给自己备注一下。访问方式：公网访问、小程序访问，可以根据自己的接入需要来选择，这会控制你的客户端请求的访问许可。APPID：当选择「小程序访问」时会出现，需要将允许访问的小程序appid填入，多个需要用,(英文逗号)隔开。服务接入节点类型：域名、IP或云托管，就是网关实例应该以什么形式发现。如果就一个实例，则直接IP，域名一般用于IP容易变化的服务器或者容器服务，另外在多地域就近配置时使用也很不错，需要搭配DNS高级解析能力；云托管需要在空间管理TAB中绑定云托管所属账号，这个另外开一篇指引。域名：填写域名，可以在公网指向网关实例所在的服务器，端口填写网关实例对外暴露的服务端口。IP：填写公网IP，能够指向网关实例所在的服务器，端口填写网关实例对外暴露的服务端口。云托管：选择云托管环境-服务作为服务接入节点。 注意：1.  多个接入层可以使用同一个网关实例，没有什么限制。一个接入层用多个实例，需要用域名来实现。2.  需要注意配置安全规则，保证网关实例对外暴露的端口能够被公网访问。不要使用七层负载均衡来转发端口，可以使用NAT网关转发。 在这里配置的如下，IP自己注意替换一下 [图片] 如果顺利完成不弹窗报错，则一切顺利，控制台可以看到节点。如果提示报错连接失败等，首先看下端口IP安全规则是否放开，注意是TCP协议。 [图片] 7.  简单访问 上面步骤的接入域名为：https://a04fa8d0a-wx79c3e1e62f1acac0.preview.wxcloudrun.com 格式大概如下：https://${接入节点ID}-${Donut平台Appid}.preview.wxcloudrun.com 下面所有访问都请替换成自己的接入域名 我们在浏览器中访问域名时，效果应该如下： [图片] 当我们访问下面地址（替换自己的前缀），效果为： https://xxx-wxxxx.preview.wxcloudrun.com/cgi-bin/scanloginqrcode?action=ask [图片] 也就是说，我们之前配置的路由，访问路径只是前缀匹配。 接下来我们新增一个配置，如下所示。记得「发布配置」线上生效。 [图片] 当我们访问下面地址（替换自己的前缀） https://xxx-wxxxx.preview.wxcloudrun.com/test?action=ask 会是404的提示。 接下来我们将一开始的index路由删掉，只保留api路由。 [图片] 再次访问时会发现，页面为正常的返回了。 [图片] 当我们再次将index路由配置回来，如下时： [图片] 一切都是可以的！ 以上是一个路由优先级的实验，当流量转发过来时，会根据配置规则列表依次匹配，当匹配存在时立刻转发，匹配不存在时再向后匹配，直到匹配到或者匹配完为止。因此如果是/根路径，一般放置在路径最后，否则将直接从/转发走。 另外还有准入域名的实验，如果感兴趣我后面再补充。原理先在这里写一下： 准入域名一般填写的是接入域名或者是自定义域名，支持*通配符；当一个路由规则配置了准入域名A，则A的流量只会匹配这一个规则，其他未填写准入域名，或者准入域名不是一个优先级的路由规则根本不匹配。准入域名可以写如下格式： 准确域名，例：www.wx.com后缀通配符，例：*.wx.com，*-wx.com前缀通配符，例：wx.*，wx-**不匹配空，比如*wx.com 将匹配 mpwx.com 而不匹配 wx.com当一个域名打到了多个路由的准入域名，则优先级按最长的来。比如www.wx.qq.com 匹配 *.wx.qq.com ，而不是 *.wx.com 四、  在客户端中使用安全网关 目前可以在微信小程序中使用安全网关，使用步骤如下： 1.  准备环境 公测阶段，小程序调用安全网关需要开白名单，可以在申请页面填写问卷提交信息，通过后重新进入小程序，能够在基础库的列表最后，看到 develop 基础库，环境准备就完成了。 [图片] 2.  获取接入节点ID 在安全网关控制台，转到「接入层」页面，将接入节点的默认域名取出，截取ID部分，如下图所示： [图片] 上图中，接入节点的ID为：a04fa8d0a-wx79c3e1e62f1acac0 这个ID需要替换成自己，每个人都不一样。 3.  配置请求域名 当前，网关的请求需要在mp后台配置request域名，直接将节点域名的完整地址填入就可以，协议为https，如下： [图片] [图片] 团队正在优化这个点，后面就不需要这个合法域名的配置了！ 4.  编写请求代码 在这里我已经写了一个代码片段，可以直接导入到IDE 小程序端调用代码片段：https://developers.weixin.qq.com/s/D5lCBnmD77Ey 导入时需要注意使用第一步申请公测时填写的APPID，不要填写其他或者接口测试号，将不会显示 develop 基础库。 [图片] 导入后，右上角点击「详情」按钮，在本地设置中，基础库选择develop [图片] 然后打开 app.js 文件，按下图所示，替换自己在第2步的接入节点ID [图片] 保存文件后，触发重新编译，在调试器console中可以看到网关请求打印的返回数据： [图片] 请求实际上有两个步骤，第一是网关的初始化，第二是call请求，在这里我对call请求做了简单的封装，并挂载在app下，大家也可以根据自己的需要封装。 [图片] 请求的触发在 pages/index/index.js 中，代码片段中初始的是前面步骤简单访问时的页面 https://xxx-wxxxx.preview.wxcloudrun.com/test?action=ask [图片] 当method为GET时，data的数据将拼接成url参数，除了path之外，其他的大部分参数都遵循wx.request。所以可以参考这里。 当将上面的data参数去掉后，由于接口的特点会直接返回页面html内容而不是JSON字符串，所以会出现下述报错。 [图片] 这是因为请求时传入datatype为json，会自动尝试对请求返回结果做json解析，如果不是json字符串，就会引起解析报错。可以直接将datatype改为text，如下图： [图片] 5.  上传体验版 公测期间，IDE内调试开发使用的是 develop 基础库，但是线上不会存在这种基础库，因此网关的调用代码需要跟随你的应用代码包一起上传。 在app.json中加入如下配置： { "cloud": true, "cloudVersion": "alpha" } [图片] 这样在你上传体验版时，网关的相关代码就随着你的代码一起打包上传了。 如果后面有一些新的特性，需要重新执行上传的步骤，其中的cloudVersion指的就是网关代码的版本，和你引入模块的版本管理形式相同，自己把握就行。 6.  降级重试 推荐大家有条件做一下降级策略，防止网关实例出现异常，或者接入层的规则出现问题，影响线上的用户调用。 先使用网关调用，网关调用失败时，使用wx.request再来一次。 异常情况下，返回的内容中有errCode，所以可以根据此来设置降级策略。 { "data": {}, "statusCode": 404, // http状态码 "errMsg": "gateway.call:ok", // 请求正常则始终为 gateway.call:ok "errCode": -651000, // 正常时无此属性。异常时会返回负值，代表云开发网关侧异常 "header": { "date": "Wed, 19 May 2021 02:37:59 GMT", "server": "envoy", "content-length": "0" }, "callID": "1665645158626-tsmg9Dpy" } 上面代码片段里，在封装的方法中有预留降级的插入为止，大家根据自己的业务做一下改造就可以。 五、  其他补充 1、 网关实例9903是正式给微信接入层做请求转发用的，端口有证书校验，不需要担心这里的攻击问题。由于默认证书可能在多处用，你可以在控制台中生成一个专属的证书，直接在对应路径替换文件，然后重启一下实例。 [图片] 2、 网关实例还有一个9902端口，是用来做路由测试的，你可以直接拼IP地址+9902端口，按照路由规则的路径测试，这个是不带证书校验的纯本地测试，也可以用于内网的流量转发，安全性不是很好，内网注意安全规则设置。 3、 网关实例还有一个19000端口，这个是管理控制台，所有人只要能访问到，就能把网关实例给停止了，还能读取你的所有配置，比较高危险了，不要裸露在外网，调试也尽量配置安全规则只允许你自己的IP访问。 [图片] 4、网关实例已经启动了，但是没在控制台的列表里显示？先看下secret有没有填写正确，重新init一下；其次再看一下网络安全规则是否放通，在实例所在服务端ping一下xds.preview.wxcloudrun.com，或者telnet一下其80端口，如果不通需要放通。 5、当配置多个网络实例时，个别实例配置不更新还是旧的？重新启动一下实例基本能解决问题，或者19000控制台进入，看一下clusters和config_dump的信息是否和配置的描述相符，不相符控制台quitquitquit，然后重新运行启动命令。 6、当确认操作步骤正确，但是效果不符合预期时，可以将启动后的log日志完整截取复制，反馈到社区相关板块。docker启动执行 docker logs envoy；linux启动，将stdout或者nohup.out的内容截取复制。 7、如果代码片段打开切换develop基础库时，长时间不启动进入页面，调试器也没有输出，请耐心等待develop基础库下载完成，会有loading的动画加载。如果等待3min仍然不变化，重新启动IDE可解决。

脚本名称： Name：微信支付 APIv3 脚本说明： 本脚本是基于 微信支付 APIv3 的 Postman请求前置脚本（Pre-Request Script）进行完善，补充了微信支付普通商户所有已知公开接口，每个接口请求预置了请求参数示例与请求成功返回的参数示例，帮助商户开发者、测试人员以及小白用户也可以快速上手。 仅修改原脚本变量为常用叫法，无其他修改部分： merchantId->mchid merchantSerialNo->merchant_serial_no merchantPrivateKey->apiclient_key.pem 使用前提条件 postman，建议注册一个账户，便于使用它各种功能，例如同步。 有一个微信支付商户号，支持微信支付直连普通商户、微信支付直连特约商户，不支持微信二级子商户。 商户 API 私钥与商户证书序列号：商户API私钥是在商家平台申请商户API证书时，会生成商户私钥，并保存在本地证书文件夹的文件 apiclient_key.pem 中，商户商户序列号可在商家平台->账户中心->API安全->管理API证书查询到。 快速开始 1、使用Fork 方式导入脚本 1.1、点击[图片]进入向导，如下图所示。 [图片] 1.2：点击 Fork Collection 进入下一步，填入标签 Fork Label 并选择目的工作台 Workspace。一般情况下，导入个人工作台 My Workspace 即可。 如未登录账户，会跳转到账户登录页面，如无账户建议先去注册一个 [图片] 1.3点击 Fork Collection 完成导入。在你指定的 workspace 中可以看到《微信支付 APIv3》了。 [图片] 2、配置Environment 环境（Environment） 是一组变量 (Varibles) 的集合。 脚本从环境中读取变量，用来计算请求的签名。 你可以从《微信支付 APIv3》提供的 商户参数模版 中 fork 一个空环境到自己的工作台。 [图片] 接下来，在你工作台的 Enviroments 中找到新建的环境，点击 Add a new varialbe 添加新的变量： 变量名 是否必填 描述 备注 server_url 必填 微信支付接口域名 固定值：https://api.mch.weixin.qq.com mchid 必填 微信支付商户号 纯数字 merchant_serial_no 必填 商户 API 证书序列号 apiclient_key.pem 必填 PEM 格式的商户 API 私钥 以 -----BEGIN PRIVATE KEY----- 开始的 PEM 格式的商户 API 私钥。 appid 必填 用于微信支付接口请求中的APPID APPID需要与填写的mchid有绑定关系 openid 选填 用于微信支付接口请求中的openid 如不配置全局变量，请求时需要将参数中的变量openid替换为实际openid值 一组常见配置如下图所示： [图片] 3、发送测试请求 此处建议，使用桌面版 Postman app 发送请求，速度更快，体验更好！ 现在回到工作台的请求构造界面，填入请求方法、URL、请求参数、Body 等参数。 工作台预置了微信支付普通商户所有请求样例供开发者参考，开发者也可以参考请求样例，构造自己的请求。 最后，选择你之前配置的 Environment，再点击地址栏右侧的Send按钮，发送请求。 [图片] 常见问题 1、发送请求时遇到错误提示“Error: Too few bytes to parse DER.”或者“Too few bytes to read ASN.1 value.” A：通常是环境 Environments 里配置的变量 merchantPrivateKey 填写有误导致的。脚本接收的私钥，以 -----BEGIN PRIVATEKEY----- 开始，以 -----END PRIVATE KEY----- 结束的一串字符串。 2、为什么我发送请求很慢？ A：如果你使用的网页版 Postman，请使用桌面版 Postman app。因为浏览器中跨域资源共享（CORS）的限制，网页版发送请求是由 Postman 后台中转的。 WeChatPay Developers QQ Group ID：684379275

文档地址：「商家转账到零钱」 我们正在对商家转账到零钱的常见问题内容进行更新和优化。暂时，我们已将相关内容删除，以便进行更全面的改进。 请您耐心等待，更新后的常见问题解答将会尽快上线。

本月可提审次数 显示服务商本月剩余可提审次数和分配的总quota值，每月1号更新 本月可加急次数 显示服务商本月剩余可加急次数和分配的总加急次数，每月1号更新 以上审核资源受服务商线上表现（小程序内容安全、活跃度、平台配合度）影响，各服务商务必做好小程序商户提供内容素材的管理，减少提审驳回情况和线上违规情况 更新时间为1号早上6点，0-6点显示的是上一月quota，6点后更新为本月 审核数据 服务商可以查看近7天、本月、上月的每日审核量、合格率和期间平均合格率、驳回原因分布 平台合格率为所选择时间周期内的合格率，合格率为重要运营指标，对服务商的资源分配有较强影响，请注意提升 一期合格率存在一定的误差，仅供参考，后续会不断完善，提升这里的数据准确度 审核队列 可以对当前审核队列中的各个审核单进行管理 审核中：提审后等待审核的单，审核时效一般为7天内，表现良好的服务商有更快审核速度 审核冻结：大批量提审未通过预检，被延后审核，建议服务商基于预检不通过原因撤回整改后再次提审，审核时效>15-30个工作日，冻结不及时撤回将被平台追加处罚 审核驳回：近7天被驳回的审核单 注意，审核队列只保留最近一次审核状态的单，如近7天被驳回的单再次提审，将从审核驳回队列中消失，进入审核中队列或审核冻结队列 审核队列支持按小程序名称，小程序appid，模板id进行搜索 搜索时，将在全部审核队列中搜索。小程序名搜索的优先级高于模板id，如”幸运58”的小程序和模板id为5828的100个小程序同时存在时，搜索58将只显示“幸运58”，搜索582才会显示模板5828 appid只支持精确匹配，名称和模板id支持模糊匹配 搜索模板id时，可以按全部单和只看审核冻结单进行筛选，方便进行批量操作 目前一页可展示100个审核单，如需查看更多，请点击页面底部的“加载更多审核单”，加载第二页，以此类推 小程序加急 服务商对于审核中和审核冻结的小程序可以进行加急操作，加急后，该审核单将优先安排审核，原本被冻结的状态也会解除 加急额度属于平台稀有资源，请谨慎使用，严禁任何形式的转卖转赠，一经发现将对quota和加急次数进行一年的处罚 单个加急：可以在小程序的明细页点击加急按钮进行 多个加急：可以点击审核队列的加急按钮，选择多个小程序进行加急 不可加急的类型：需要被报备网信办等机构的审核，无法加急，提示加急失败，加急额度返还 小程序撤回 当发现bug，或者预检不通过导致大批小程序被冻结时，服务商可以操作撤回这批小程序，整改后再次提审。 对大批量问题提审单撤回有助于提升服务商合格率，降低对平台资源消耗。预检不通过的冻结单未及时撤回将会被处罚 单个撤回：可以在小程序的明细页点击撤回按钮进行 批量撤回：可以点击审核队列的撤销审核按钮，选择多个小程序进行撤回，批量操作时，可以基于模板去筛选，可以按照只看冻结去筛选 推荐操作流程：当服务商需要对某个模板id，如5234模板id中全部提审单或全部冻结审核单进行撤回时，建议点击撤销审核按钮，进入选择审核单页面，搜索模板5234，在进入的模板页，点击筛选选项（全部/只看审核冻结），然后点击全选，可以看到本次要撤回的小程序个数，最后点击确定 批量撤回在单数较多时，将生成一个后台异步任务执行，执行结束后将批量撤回结果反馈回来，大批量的撤回可能要等待较久时间 不可撤回的类型： 1，单个小程序每月撤回次数上限为10次，超过时不可撤回 2，已经被其他渠道（如API接口）撤回的单，不可重复撤回 3，其他 客服专区 本次审核专区将为部分服务商开放客服专区入口，客服专区包括机器人客服为服务商提供常用知识库，以及人工客服解决服务商具体问题 开放范围：基于服务商每月quota排名进行分配，一期开放100个，后续将不断放开，直至覆盖全部服务商 客服工作时间：工作日：9:00-12:00,14:00-18:00，特殊时期以平台公告为准 客服问题范围：小程序运营规则、服务商运营政策、提审/审核/线上处罚常见问题咨询、服务商助手体验bug问题等 使用过程中任何问题都可以通过客服入口留言，如无客服入口可以通过开放社区进行反馈，我们将以帮助服务商提高获取信息和办理业务的效率为核心目标，不断完善服务商助手小程序。 最后更新时间：2020年3月5号

各位亲，面对帐号注销是不是束手无策呢？帐号如何注销，怎么注销，注销需要提供什么信息内容呢？请仔细往下看看 小程序 关于小程序注销的条件，若未冻结的个人帐号和组织类帐号就不 一 一 细讲，详情请参腾讯客服文档：https://kf.qq.com/product/wx_xcx.html#hid=2826 1：小程序注销之政府无对公账户： 详细流程请参考：https://kf.qq.com/faq/190104YnQbYN190104RzaYba.html 政府的有一致主体是提供一致的主体证件和公章，如果有变更请提供4项材料：因机构改革、单位合并、撤一建一等情况，导致机构主体名称有变更，提供以下材料申请注销： 1、更名相关的红头文件（有鲜章）； 2、主体名称变更情况说明书（加盖新主体公章）； 3、变更后新主体的主体证件；（原件拍照或加盖公章的复印件） 4、注销申请函（加盖新主体公章）； 2：小程序注销之个体工商户 若个体工商户存在对公账户，请使用对公账户小额打款注销 若个体工商户类型无对公账户注销小程序工单指引流程如下 工单所需材料 1、小程序绑定邮箱/原始ID： 2、主体证件材料（营业执照/组织机构代码证等）： 3、小程序绑定的法人身份证原件正反面的清晰扫描件或照片： 4、小程序的注销书面申请，申请书必须加盖公章。（若个体户没有公章可支持法人手写签名） 附注：注销申请书模板（https://kf.qq.com/faq/200306R7N3mI200306I3aEBz.html） 材料提交链接：https://kf.qq.com/touch/bill/200306selfqaafe6c551.html（手机端打开） 3：小程序注销之帐号主体已注销 主体已注销小程序工单指引流程如下， 1、小程序绑定邮箱/原始ID： 2、主体注销证明： 3、小程序绑定的法人身份证原件正反面的清晰扫描件或照片： 4、小程序的注销书面申请，企业账号的申请必须有加盖公章的函件（公章被收的请法人手写签字）附注：注销申请书模板（https://kf.qq.com/faq/200306R7N3mI200306I3aEBz.html） 材料提交链接：https://kf.qq.com/touch/bill/200306selfqaafe6c551.html（手机端打开） 4:小程序注销之门店小程序 门店小程序依附于公众号，不支持单独注销，公众号注销门店小程序才支持注销 5:公众号正常运营，门店小程序如何释放昵称 如果需要释放该小店小程序昵称，发送邮件到“miniprogram@tencent.com”，标题格式【关于XXX名称释放请求】，需提供以下材料： 1、小程序帐号（原始ID）； 2、绑定的管理员微信号； 3、小程序主体营业执照等主体证件； 4、小程序所有者的书面申请，申请书需加盖小程序主体公章；（个体户无公章：申请书需要加上法人签名）； 邮件内容：需包含背景、释放请求原因。 6:复用公众号资质快速注册的小程序如何注销 复用资质申请的小程序是独立存在的，请按照正常流程注销即可 7:注册小程序选择微信认证，若未完成微信认证如何注销呢？ 小程序30天未认证或认证失败且7天内未发起认证不会释放邮箱，但该邮箱支持重新注册小程序，会释放主体信息、管理员信息、昵称。 公众号 关于公众号若未冻结的个人帐号和组织类帐号就不一一细讲，详情请参考腾讯客服文档：https://kf.qq.com/product/weixinmp.html#hid=2267 1：公众号注销之政府无对公账户： 详细流程请参考：https://kf.qq.com/faq/190531qyuuiY190531BjyyEv.html 政府的有一致主体是提供一致的主体证件和公章，如果有变更请提供4项材料：因机构改革、单位合并、撤一建一等情况，导致机构主体名称有变更，提供以下材料申请注销： 1、更名相关的红头文件（有鲜章）； 2、主体名称变更情况说明书（加盖新主体公章）； 3、变更后新主体的主体证件；（原件拍照或加盖公章的复印件） 4、注销申请函（加盖新主体公章）； 2：公众号注销之个体工商户 若个体工商户存在对公账户，请使用对公账户小额打款注销 若个体工商户类型无对公账户，请使用法人扫脸注销公众号 详情请参考：https://kf.qq.com/faq/220309bUvmIB220309BbAjMz.html 3:公众号注销之帐号主体已注销 主体已注销公众号工单指引流程如下， 1、公众号绑定邮箱/原始id/微信号：  2、主体注销证明： 3、公众号绑定的法人身份证原件正反面的清晰扫描件或照片： 4、公众号的注销书面申请，企业账号的申请必须有加盖公章的函件（公章被收的请法人手写签字） 附注：注销申请书模板（http://kf.qq.com/faq/171018R3IVBF171018INjUvA.html ） 材料提交链接：https://kf.qq.com/touch/bill/180227selfqa9ab6ac55.html（手机端打开） 4:未注册成功的帐号如何注销 若帐号当时没有走完注册流程且长期没有登录该帐号，到期会被系统注销。没有走完注册流程的帐号不占用个人信息，也不支持找回，建议重新注册 5:注册公众号选择微信认证，若未完成微信认证如何注销呢？ 若公众号注册时选择微信认证，自注册日起30天内未进行认证（第30天仍在认证中不算），点击“重新提交材料”，帐号角色变为注册失败，不会释放帐号邮箱，但该邮箱支持重新注册公众号，会释放主体信息、管理员信息、昵称， 6:小程序公众号注销确认期 注销确认期的7天内每天会发送一次确认注销的通知，若管理员一直未点击确认注销则默认取消注销，注销失败。因此管理员请关注公众平台安全助手！！！

为进一步规范开发者调用用户信息相关接口或功能，提升用户体验，平台将对部分用户信息相关功能及接口进行调整，具体如下： 访问蓝牙、添加通讯录联系人、添加日历事件需要用户授权小程序处理用户的个人信息，需要获取用户明示同意，平台计划从2022年2月21日24时起对以下接口增加用户授权： 访问蓝牙：调用wx.openBluetoothAdapter、wx.createBLEPeripheralServer，需要授权scope.bluetooth添加通讯录联系人：调用wx.addPhoneContact，需要授权scope.addPhoneContact添加日历事件：调用wx.addPhoneRepeatCalendar、wx.addPhoneCalendar，需要授权scope.addPhoneCalendar开发者可在平台调整前提前增加使用 wx.getSetting 获取用户当前的授权状态的逻辑，若授权状态为false可以调用 wx.openSetting 打开设置界面，引导用户开启授权。 授权功能详细说明可参考：官方文档 <open-data>组件功能调整开发者在未获取用户明示同意的情况下通过 <open-data>组件 在小程序中展示用户个人信息，用户容易误以为自己的个人信息在未授权的情况下，被小程序获取。平台计划从2022年2月21日24时起回收通过<open-data>展示个人信息的能力，若小程序需收集用户昵称头像等信息，可以通过 头像昵称填写功能 功能进行收集。具体回收方式为： 头像展示 灰色头像用户昵称展示“微信用户”用户性别、地区、语言展示为为空（“”）小程序通过<open-data>展示群名称能力保留，平台会针对小程序生命周期内首次调用该组件展示群名称向用户提示：“群名称仅你可见，小程序无法获取。” 获取手机号能力安全升级此前小程序获取用户手机号是通过基础库接口直接获取encryptedData后进行解密。从基础库2.21.2版本起，回调参数中增加code参数，开发者获取code参数后，通过服务端auth.getPhoneNumber接口，使用code换取encryptedData，用于解密手机号。 为不影响开发者现有逻辑，原有基础库接口中的encryptedData参数依旧保留，建议开发者尽快使用新的方式获取用户手机号。 详细功能描述可参考 官方文档 微信团队 2021年12月27日

一、试用小程序产品能力正式上线第三方开发者可通过创建试用小程序接口提供快速注册试用小程序的能力，商家只需填写小程序名称、头像并进行实名授权即可创建试用小程序，总共耗时约在1分钟。体验后完成认证流程，即可转为正式小程序。 二、第三方平台票据长时间不接收则主动停止推送通知为了减少无效的票据推送以及无效的告警信息，从2021年2月1日起，平台将停止推送票据给超过90天没有正确接收component_verify_ticket的第三方平台，被停止推送的第三方平台若要重新启用服务可通过启动ticket推送服务接口重新启动推送。 三、第三方平台全网发布自动化测试新增测试号为了提高第三方平台全网发布自动化测试的效率，从2021年1月18日起，平台将分别新增4组公众号和小程序的专用测试号。详情可查看平台型第三方平台全网发布接入检测说明，请及时对新增的测试号配置测试 Case，以免影响提交第三方平台全网发布。 四、小程序开放接口wx.addCard将不再支持用户单次领取多张卡包会员卡为进一步维护用户端体验，2021年1月20日起，小程序开放接口wx.addCard将不再支持用户单次领取超过1张的“卡包会员卡”，其他功能不受影响。详情参考： https://developers.weixin.qq.com/community/develop/doc/00060aa283430885398b44a7c5d001?blockType=1 五、小程序类目资质更新[图片] 详情请参考小程序开放的服务类目 第三方快速创建的小程序可选择的类目参考“第三方平台-快速创建小程序接口-类目参考表”

提供天气、北京实时公交、全国地铁站、火车票余票查询、车辆限行、全国油价、地图导航、路线规划、电影资讯、台风运行轨迹等信息。