运营指标一直是优秀，审核一般都在一小时内通过。

今天发现性能也优秀了，真不容易。老实讲指标有点苛刻，花了不少心思，不知道是不是近期标准降低了。

还差用户指标。

今晚 Neo 发了三个抽奖，又翻车了一把，比上次程度轻一些（超出了一个名额），不过终究还是翻了。

聊完之后想到解决方案。一方面看看代码问题，一方面在规则上也要做一些优化，避免漏洞。

涂涂同学说，明后天可能要用抽奖。

那今天就加急上线。

把抽奖功能从微商店助手里面拆出来，单独做一个小程序，后面群活动类的应用都在这个小程序里做。

最近陆续发现有用户使用，初步验证市场，而且发现这工具自带推广属性，有一个人用，就会带来更多人用。

早上发现有用户凌晨反馈 bug，浑身来劲。

晚上八点 Neo 老师在群里抽书，并发有点大，翻了小车，还好问题不是太大。

云函数得优化下。

第一位种子客户的首日成绩，给我不小鼓舞。

这个项目未必能赚大钱，但一定可以帮助到许多实体小店的老板们。

采纳了 Nico 和客户的建议，把小程序名称由 群友之间 改成 实体小店助手。

2020-7-3 更新：

昨晚 12 点多想到一个名字，试一下居然还没被注册，微商店助手。这名字，有点高大上。问了下 Neo，也说好。

再次改名。

微信官方的叫小商店助手，这两名字还挺配对。

小程序新的 canvas 2d 坑有点多，粗略统计有以下 6 坑：

1、canvasToTempFilePath 生成的临时文件在开发工具中显示不了，在真机上可以显示。刚开始没用真机测试，一直在开发工具中调试，浪费不少时间。

2、canvas 的尺寸要写在 wxml 中才会跟随屏幕比例自适应大小。切记，不要写在 css 中，加 important 也没有。假如你也是用 Taro，那就这样写：

<Canvas type="2d" className="canvas" style={{ width: '375px', height: '525px' }} id="my-canvas" />

3、图片不能直接使用 src 画在 canvas 上，要先 createImage，接着 onLoad 后再画在 canvas 上。

wx.getImageInfo({
  src: 'testPath/test.png',
  success: (res) => {
    const image = canvas.createImage()
    image.src = res.path
    image.onload = () => {
      ctx.drawImage(image, 0, 0, 100, 100)
    }
  }
})

4、生成小程序码返回的临时文件不能直接画在 canvas 上，可以保存到云端再 download 下来使用。

5、getImageInfo 也有坑，取不到图片会一直 pending，要使用 wx.cloud.downloadFile 接口判断之前是否生成过小程序码，有的话直接返回 fileId，无需再次生成。

6、最后一个大坑（官方已经优化解决），就是云开发数据库自动生成的 id。早期的 id 是超过 32 位的，不能用来作为 scene，最近他们改成了 32 位。所以这里需要作个判断，如果不考虑早期数据，在页面上不显示生成海报的入口就行了。

一个月不到挂了两次。

6 月 5 号上了 v2.4.0，按常规，接下去是打补丁和小优化，发 v2.4.1，结果发现这个版本似乎没啥大 bug， 于是这补丁打着打着就变成 v2.5.0 了。

通常补丁都是一天或者两天内打完，超过三天就不是补丁了，按新功能的日程开发，通常不超过一周。如果眼看要超过一周，那就精简功能，做好的先上，剩下的放到下一版。

快速迭代才能保持亢奋。

最近这两个月提交审核好像坐上了高速列车，比加急服务还快，博客这几个字还没打完就通过了。

拿了一个相对简单的页面来做实验，还是可以做到四项 100 分，不过要整个小程序（目前大概 30 个页面）都做到四项 100 就有挑战了。