微信JSAPI支付,配置支付授权目录,添加后无提示,也无添加记录. 尝试多次,清空缓存,切换网络,重新登录等多种方法也无效

由于刚才发了一遍都邀请答题了，但是看不到了，所以再发一遍。 操作时间：2021-12-31 09:42:00  复现路径： 1.下载后台文件， 修改[图片]， 保存[图片]。用WPS保存每次都提示该问题。MicrosoftOffice不认识csv文件，认为它是文本。 2.确认上传文档与已有关键词无冲突：[图片]。 3.点击上传，提示“关键词无效，请确认内容信息后再添加”：[图片] 注：只有直接下载的文档不修改，且与已有的关键词不重复时导入才能成功。

目的：在开发管理-内容风控中批量导入关键词。 bug：导入失败，一直提示“关键词无效，请确认内容信息后再添加”。手动添加可以，但是文件批量导入不行。 复现过程： 1.下载后台提供的“自定义关键词.csv”文件，修改内容，保存。但是我用wps保存时提示如下[图片]，依然选择保存。每次保存都会提示。Microsoft Office的表格打不开csv文件认为它是文本。 2.查看文件内容与已有关键词是否重复：文档[图片]，已有关键词[图片]，无重复点击上传[图片]。 3.上传结果：提示关键词无效[图片]。 只有直接从后台下再的文档不修改，直接上传且已有关键词与下载的文档关键词无冲突时才能成功。

开发过小程序的朋友们应该都遇到这样的情况，可能很多个页面有相同的函数，例如[代码]onShareAppMessage[代码]，有什么最佳实践吗，应该如何处理呢？ 本次开发技巧，我从以下几种解决办法剖析： 将它复制粘贴到每个地方（最烂的做法） 抽象成一个公共函数，每个[代码]Page[代码]都手动引用 提取一个behavior，每个页面手动注入 通过[代码]Page[代码]封装一个新的[代码]newPage[代码]，以后每个页面都通过[代码]newPage[代码]注册 劫持Page函数，注入预设方法，页面仍可使用[代码]Page[代码]注册 复制粘贴大法 这是最直观，也是初学者最常用到的办法。也是作为工程师最不应该采取的办法。这有一个致命的问题，如果某一天，需要改动这个函数，岂不是要将所有的地方都翻出来改，所以这个办法直接否决。 抽象公共函数 这种方式，解决了复制粘贴大法的致命问题，不需要改动很多地方，只需要改动这个抽象出来的函数即可。但是其实，这个方式不便捷，每次新增页面都需要手动引入这个函数。 以下都通过[代码]onShareAppMessage[代码]方法举例。 假设在[代码]app.js[代码]通过[代码]global[代码]注册了[代码]onShareAppMessage[代码]方法： [代码]// app.js global.onShareAppMessage = function() { return { title: '我在这里发现了很多好看的壁纸', path: 'pages/index/index', imageUrl: '' } } [代码] 那么此时每次新增的Page都需要这样引入： [代码]// page.js Page({ ...global.onShareAppMessage, data: {} }) [代码] 这样的缺点也是非常明显的： 创建新页面时，容易遗忘 如果多个相同的函数，则需要每个独立引入，不方便 提取Behavior 将多个函数集成到一个对象中，每个页面只需要引入这个对象即可注入多个相同的函数。这种方式可以解决 抽象公共函数 提到的 缺点2。 大致的实现方式如下： 同样在[代码]app.js[代码]通过[代码]global[代码]注册一个[代码]behavior[代码]对象： [代码]// app.js global.commonPage = { onShareAppMessage: function() { return { title: '我在这里发现了很多好看的壁纸', path: 'pages/index/index', imageUrl: '' } }, onHide: function() { // do something } } [代码] 在新增的页面注入： [代码]// page.js Page({ data: {}, ...global.commonPage, }}) [代码] 缺点仍然是，新增页面时容易遗忘 封装新Page 封装新的[代码]Page[代码]，然后每个页面都通过这个新的[代码]Page[代码]注册，而不是采用原有的[代码]Page[代码]。 同理，在[代码]app.js[代码]先封装一个新的[代码]Page[代码]到全局变量[代码]global[代码]： [代码]// app.js global.newPage = function(obj) { let defaultSet = { onShareAppMessage: function() { return { title: '我在这里发现了很多好看的壁纸', path: 'pages/index/index', imageUrl: '' } }, onShow() { // do something } } return Page({...defaultSet, ...obj}) } [代码] 往后在每个页面都使用新的[代码]newPage[代码]注册： [代码]// page.js global.newPage({ data: {} }) [代码] 好处即是全新封装了[代码]Page[代码]，后续只需关注是否使用了新的[代码]Page[代码]即可；此外大家也很清晰知道这个是采用了新的封装，避免了覆盖原有的[代码]Page[代码]方法。 我倒是觉得没什么明显缺点，要是非要鸡蛋里挑骨头的话，就是要显式调用新的函数注册页面。 劫持Page 劫持函数其实是挺危险的做法，因为开发人员可能会在定位问题时，忽略了这个被劫持的地方。 劫持[代码]Page[代码]的做法，简单的说就是，覆盖[代码]Page[代码]这个函数，重新实现[代码]Page[代码]，但这个新的[代码]Page[代码]内部仍会调用原有的[代码]Page[代码]。说起来可能有点拗口，通过代码看就一目了然： [代码]// app.js let originalPage = Page Page = function(obj) { let defaultSet = { onShareAppMessage: function() { return { title: '我在这里发现了很多好看的壁纸', path: 'pages/index/index', imageUrl: '' } }, onShow() { // do something } } return originalPage({ ...defaultSet, ...obj}) } [代码] 通过这种方式，不改变页面的注册方式，但可能会让不了解底层封装的开发者感到困惑：明明没注册的方法，怎么就自动注入了呢？ 这种方式的缺点已经说了，优点也很明显，不改变任何原有的页面注册方式。 其实这个是一个挺好的思路，在一些特定的场景下，会有事半功倍的效果。

自定义navigate+分包+自定义tabbar，有需要的可以拿去用用，可能会存在一些问题，根据自己的业务改改吧 大家也可以多多交流 代码片段：在这里 {"version":"1.1.5","update":[{"title":"修复 [复制代码片段提示] 无法使用的问题","date":"2020-06-15 09:20","imgs":[]}]} 更新日志:     2019-11-25  自定义navigate 也可以调用wx.showNavigationBarLoading 和 wx.hideNavigationBarLoading     2019-11-25  页面滚动条显示在自定义navigate 和 自定义tabbar上面的问题(点击“体验custom Tabbar” [图片] [图片] 其他demo: 云开发之微信支付：代码片段

1. 层级关系 坑爹的原生组件（canvas等）层级最高，虽然官方个了个cover-view，但是这个覆盖是依赖渲染的先后顺序的，就是说如果cover-view是在canvas前面的，canvas反而会覆盖掉cover-view。然鹅整个架构的设计理念都是数据驱动的，你没办法只能打乱所有的布局来避免这个问题，布局结构乱了，又引发了其他的问题。 2. 插槽slot 自定义组件时slot你不管放在什么位置，渲染时就是都是直接追加在你自定义内容的后面，而且放的位置不一样，虽然都是追加在后面，但是有些样式不生效，布局乱掉，位置乱掉。 3. 自定义tabbar 虽然从2.5之后，官方给出了官方方案，但是当你自定义的时候，page不会像原来那样高度只到tabbar之上，page区域会拉升到屏幕最底部，tabbar会覆盖一部分的内容。 4. 自定义顶部导航栏navbar 这个没有官方方案，所以必须自己使用cover-view来自定义，首先那个胶囊按钮不同手机的位置就是不一样和单位转换无关，还不能获取，导致你自定义navbar的时候不美观，上面就是要居中，苦了开发。 然后这个和tabbar一样会使page拉伸到顶部，难点不是给page加个上边距，而是你需要下拉刷新的时候是从page的顶部开始的，你的下拉完全被自定义navbar挡住了。别跟我说设置margin，下拉刷新就是用的margin，冲突的。 最后还是原生组件层级导致的，你的navbar必须是最后渲染才行，要不然会被其他覆盖，你上滑时就知道了。我想过其他的方案，比如干脆navbar加个slot，把页面内容都放到slot，然后你就知道第二个坑哪里来的了。没办法还是修改布局得了。 5. 关于界面的顶层布局 一直以为是page标签，其实不是，坑。当你自定义tabbar的时候你就会看到整个布局是下面这个样子的。 [代码]<tab-bar>...</tab-bar> <page>...</page> [代码] 我去，小于号竟然还被转义了。 page是个奇怪的东西，你设置高度100%，高度是一屏，但还是会被内容顶上去，滚动依然会被整体上滑。不知道微信是个什么逻辑。 canvas等原生组件的滑动又只能是依赖page的整体上滑，巨坑无比。比放在scroll-view等里面滚动又有bug，这个我想你们都遇到过。 先到这里，其实坑还有很多很多，但有些是业务上的，不是每个人都会遇到，但说回来，业务是在发展的，这些坑以后必然是要踩的。做个码农不容易啊。

说到程序开发，bug总是如影随形，开发过程中50%的时间在debug，30%是在修之前发布了的bug，毫不奇怪。 如何把bug见到最少，甚至是0 bug呢？看似遥不可及，但实际是可以追求的，方法就是完整科学的测试，事实上，测试和使用是证明代码没bug的唯一方式。 测试又分为白盒测试跟黑盒测试，一般来说，产品上线前经过测试同学测试做的功能测试都是黑盒测试，毕竟测试同学不可能了解所有的代码，而能做白盒测试的，都是最了解代码的人，也就是写代码的程序员。而只有最了解代码的人也才能写出最完善的测试用例。而单元测试就是白盒测试里面最重要的方法之一。 很多程序员，特别是前端程序员是没有写单元测试的习惯。诚然，写单元测试其实是比较费劲的事情，特别在前端领域，涉及大量ui及交互操作，写单元测试尤为困难。但是近年来js模块化越演越烈，模块化的同时也使得写单元测试变得更容易了。 本文就致力于探讨在当前的开发环境下做单元测试的一些实践方法。 先介绍下被测试的对象 —— 一个js工具库，这个公共库有几个比较重要的标签：ES6，移动端，浏览器端。 从最简单的讲起吧，js的测试框架其实不算少，比较有名的有mocha，Jasmine，Jest等，基本用法都比较简单明了，看看官方文档就大概能写出来一些测试用例了。下面我主要使用比较强大mocha来作为主要的测试框架。 下面是我项目中的一份test.js： [代码]import * as lib from './index'; import chai from 'chai'; let expect = chai.expect; describe('testcase',function(){ it('single one',function(){ let a = 'aer'; expect(a).to.be.a('string'); }); it('test /common/getUrlParam',function(){ let ret = lib.common.utils.getUrlParam('a','http://vip.qq.com?a=1'); expect(ret).to.equal('1'); ret = lib.common.utils.getUrlParam('a','http://vip.qq.com#a=1'); expect(ret).to.equal('1'); ret = lib.common.utils.getUrlParam('a','https://vip.qq.com?a=1'); expect(ret).to.equal('1'); ret = lib.common.utils.getUrlParam('b','http://vip.qq.com?a=1&b=2'); expect(ret).to.equal('2'); ret = lib.common.utils.getUrlParam('a','http://vip.qq.com?a=1#a=2'); expect(ret).to.equal('2'); }); }); [代码] ES6 这份test.js包含两个测试用例，第一用例是用于测试的，单纯试用下测试框架跟断言库的功能，第二个用例是对库文件中一个模块的一个方法的测试用例，估计前端大佬们看看方法名大概都能看懂是什么东西，我就不多说了。写好test.js后就跑了试试看，运行mocha，然后马上就报错了： [代码]JUSTYNCHEN-MC0:gxh-lib-es6 justynchen$ ./node_modules/.bin/mocha /path/to/your/project/somelib/test.js:1 (function (exports, require, module, __filename, __dirname) { import * as lib from './index'; ^ SyntaxError: Unexpected token * at new Script (vm.js:79:7) at createScript (vm.js:251:10) at Object.runInThisContext (vm.js:303:10) at Module._compile (internal/modules/cjs/loader.js:656:28) ... [代码] 我当前的node版本是v10.13.0（对，近日node的LTS版本已经升级到10.x了，没升的同学赶紧玩玩吧），按理说是默认支持import的。仔细一看报错，原来mocha不是直接执行test.js，而是把test.js的内容放到了一个沙箱里面执行的。那就有点蛋疼了，就算node新版本已经支持了也没法直接使用。第一想法就是先把代码编译了，然后再做测试，可是测试的代码都是编译后的代码，就算测试出什么问题，还要经过sourcemap才能找到源码中出错的位置，想想都蛋疼。 官方当然是不会这么蠢的，稍微找了下官方的方案，不难找到对es6的支持。babel提供了一个register，给到不同的应用去做转换，mocha同样也可以使用这个register先转换然后再跑。命令就变成了这个： [代码]mocha --require babel-core/register [代码] 同时，package.json里面的选项也要加上babel的选项： [代码]"babel": { "presets": [ "stage-3", "latest" ], }, [代码] 当然，相关的包（babel,babel-core）也要同时装上，大家都懂的后面我就不提了，缺啥装啥就对了，后面提到的工具如没特别说明都是指npm包。 到这里相关的资料还比较好找，接下来就是干货了。 browser 运行上面改造过的mocha命令，是不是就ok了呢？当然没那么顺利，这里遇到了第二个坑： [代码]./node_modules/.bin/mocha --require babel-core/register /path/to/your/project/somelib/common/cache.js:15 var storage = window[storageType]; ^ ReferenceError: window is not defined at initStorage (/Users/justynchen/....../cache.js:10:16) at Object.<anonymous> (/Users/justynchen/....../cache.js:41:16) at Module._compile (internal/modules/cjs/loader.js:688:30) [代码] 前面也说了这份库是给移动端浏览器用的，其中就免不了使用一些浏览器的API，这些API在node里面都是不存在的。解决方案有两个： 直接不测试使用了浏览器API的代码，使用前先做检测并return掉。 找一个模拟浏览器的环境，让浏览器的API也能正常执行。 方案一是我们不愿意看到的，特别是一份浏览器用的库，不测试浏览器相关的特性那跟咸鱼有什么区别【手动狗头】。那就按方案二的思路想走吧，想到node模拟浏览器的环境，脑中浮现的第一个名词估计大部分人跟我都一样 —— electron。作为业界最著名的“没有界面的浏览器”，用在这里再合适不过了。但是该怎么用呢，稍作搜索，果然已经有前人做了相应的工作，有一个electron-mocha的工具刚好就是把这两个东西合了起来。 然后命令就变成了这样： [代码]electron-mocha --renderer --require babel-core/register [代码] 然后终于得到了我们想要的结果： [代码]JUSTYNCHEN-MC0:somelib justynchen$ ./node_modules/.bin/electron-mocha --renderer --require babel-core/register testcase ✓ single one ✓ test /common/getUrlParam 2 passing (37ms) [代码] 完美~（请自动脑补金星脸） 可是，就这么完了是否有点意犹未尽？ 是的，就是缺了点什么东西，说好的0 bug呢，写了测试用例就能保证0 bug了么？肯定不是的，如果有的地方就是有bug，只是用例没写好，并没有覆盖到有问题的地方怎么办？只有写“全”了的测试用例才能保证0 bug。如何确保用例写全了呢？请往下看。 代码测试覆盖率 这里引入一个概念，叫代码测试覆盖率，大概意思就是说，你的测试用例到底覆盖了多少的代码。理想情况下，肯定只有100%覆盖所有代码的用例，才能说自己经过测试的代码是0 bug的，当然现实中100%总是很难的，一般覆盖到90%以上已经是比较理想的情况了。 JS也有统计代码测试覆盖率的库 —— Istanbul。这库名也很有意思，库名直译是伊斯坦布尔，没错，就是那个正常中国人可能名字都没听说过的中东城市。这个地方有个特产是毯子，然后这个库的作者就想，覆盖就是毯子该做的事情嘛，脑洞一开就把库名起作Istanbul了。 继续“稍微读下文档”，哦，原来这个库有一个命令行工具，nyc，装上然后放到执行命令的前面就能做覆盖率统计了。然后就有了下面的命令 [代码]nyc --reporter=lcov --reporter=text electron-mocha --renderer --require babel-core/register [代码] 其中reporter是定制化报告的内容，默认是text，lcov就是生成一个网页版的覆盖率报告。 然而，跑完之后是酱婶儿的 [代码]JUSTYNCHEN-MC0:somelib justynchen$ ./node_modules/.bin/nyc ./node_modules/.bin/electron-mocha --renderer --require babel-core/register testcase ✓ single one ✓ test /common/getUrlParam ✓ aidMaker test 3 passing (18ms) ----------|----------|----------|----------|----------|-------------------| File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s | ----------|----------|----------|----------|----------|-------------------| All files | 0 | 0 | 0 | 0 | | ----------|----------|----------|----------|----------|-------------------| [代码] 苍天大地啊，为啥啥都没有。。。。 这里就又开始苦逼的查资料环节，不得不吐槽一下，这个资料是真不好查，中文资料没有就算了，反正早习惯了，文档翻遍了还是没有。。。那就过分了。然后查了下别的资料，基本都是mocha跟Istanbul一起用的，也没有electron-mocha相关的。 最后还是找到了github的issue里面，果然有人是跟我有类似问题，找了几个提了没啥回音的，终于找到一个maintainer的回复。里面指向了一个插件 —— babel-plugin-istanbul。 皇天不负有心人，得益于之前已经引入了babel，这里只要加上这个插件就ok了，照例先装包，package.json里面的babel配置加上这个参数 [代码]"babel": { "presets": [ "stage-3", "latest" ], "env": { "test": { "plugins": [ "istanbul" ] } } }, [代码] 然后按照插件的README改一下命令，最终得到了这个 [代码]cross-env NODE_ENV=test nyc --reporter=lcov --reporter=text electron-mocha --renderer --require babel-core/register [代码] 然后一跑。。。发现，x你x的。。。跟前面的输出一毛一样，啥的没有！！！ 冷静一下，再回头看看maintainer回复的原话 Basically, yes. Note that if you’re using babel already you can now just use the excellent istanbul-plugin to instrument your code. If you do this, you really only need to write out the __coverage__ object after the tests have run. (I write them out for both renderer and main thread tests, then combine them using nyc report from the command line). 里面提到了一个奇怪的参数__coverage__，又查一波资料，在这个项目的某些commit comment里面看到这个__coverage__的蛛丝马迹，这东西好像是一个全局参数，那这个参数有啥用咧？管他有用没用，打出来看看再说，然后就在test.js里面吧这个参数打了下，发现，卧槽，还真有，而且里面不就是覆盖率的数据么？？？？ 嗯，有数据。。。怎么生成报告呢？作者写的语焉不详。。。啥叫write out这个参数然后配合nyc report命令就能用了，write到啥地方啊，咋配合啊！！！ 这个时候就想到了Istanbul的一些特性，其实它是会在测试后生成一个.nyc_output的文件夹的，打开一看，里面不就是一些json么！那是不是直接write进去就好了呢？文件该叫啥名字咧，原来的文件都是hash命名的，这hash哪来的呀。不管了写了再说，然后得到如下test.js [代码]import * as lib from './index'; import chai from 'chai'; import fs from 'fs'; let expect = chai.expect; describe('testcase',function(){ it('single one',function(){ let a = 'aer'; expect(a).to.be.a('string'); }); it('test /common/getUrlParam',function(){ let ret = lib.common.utils.getUrlParam('a','http://vip.qq.com?a=1'); expect(ret).to.equal('1'); ret = lib.common.utils.getUrlParam('a','http://vip.qq.com#a=1'); expect(ret).to.equal('1'); ret = lib.common.utils.getUrlParam('a','https://vip.qq.com?a=1'); expect(ret).to.equal('1'); ret = lib.common.utils.getUrlParam('b','http://vip.qq.com?a=1&b=2'); expect(ret).to.equal('2'); ret = lib.common.utils.getUrlParam('a','http://vip.qq.com?a=1#a=2'); expect(ret).to.equal('2'); }); after(function() { fs.writeFileSync('./.nyc_output/coverage.json',JSON.stringify(__coverage__)); }); }); [代码] 终于生效了 [代码]JUSTYNCHEN-MC0:somelib justynchen$ tnpm run test > @tencent/somelib@1.0.1 test /path/to/your/project/..... > cross-env NODE_ENV=test nyc --reporter=lcov --reporter=text electron-mocha --renderer --require babel-core/register testcase ✓ single one ✓ test /common/getUrlParam 3 passing (26ms) ----------------------|----------|----------|----------|----------|-------------------| File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s | ----------------------|----------|----------|----------|----------|-------------------| All files | 5.96 | 3.3 | 3.6 | 6.02 | | gxh-lib-es6 | 0 | 0 | 0 | 0 | | index.js | 0 | 0 | 0 | 0 | | gxh-lib-es6/business | 16.89 | 8.84 | 3.45 | 16.89 | | aid-maker.js | 80 | 66.67 | 100 | 80 | 325,340,341,344 | cgi-handler.js | 0 | 0 | 0 | 0 |... 57,159,160,161 | index.js | 0 | 0 | 0 | 0 | | pay.js | 0 | 0 | 0 | 0 |... 86,88,89,91,97 | .... [代码] 至此，终于可以说出那句 完美~ 附录 整体架构图 [图片] 后记：整个单元测试的技术其实都没什么困难的，基本上都有库可以用，主要把时间都花在了查询资料上面。写本文的时候好像是遇到问题马上就找到了解决方案，其实真实情况是，几乎遇到每个坑都会试了至少一两个走不通的方案，最后才找到正确的方案的，所以对于不经常关注社区的人来说，单靠文档是很难解决所有的问题的。单从前端领域来看，前端的技术日新月异，再完善的文档都很快会跟不上发展的步伐，还是要靠多关注社区的动向，甚至多参与社区的讨论和建设才不至于在需要用某些技术的时候无从下手。