共计 1157 个字符，预计需要花费 3 分钟才能阅读完成。
hello 你好 我是大粽子。
工作中的填坑就像常识一样，得一步步来，就像我上面遇到的这个问题一样。
这个是我一部分的记录日志
| 后果 | 扫码环境 | 生成环境 |
|---|---|---|
| 没问题 | 开发工具模仿 | 开发工具生成 |
| 有问题 | 本地和开发工具模仿 | 本地和开发工具模仿生成 |
| 有问题 | 线上 | 线上 |
找问题
从上线的小表格能够看出本地模仿环境没有问题，线上有问题，本地和线上相互生成和扫码会存在问题，那么问题绝对就好找了。
顺着业务逻辑一步步确认下。
前端在商品详情中获取到商品详情之后，传递参数给后盾，后盾生成小程序码的 Base64 数据再给前端，剩下的将 html 绘制成图片的性能就是前端自主操作的了。
商品详情 –》获取小程序码 –》绘制 canvas 后保留图片。
那么先从小程序生成二维码动手
嗯参数没问题
拿着数据去解析下看看后盾给生成的对不对？（狗头），用工具还原 Base64 图片。
截图保留下，去小程序验证下，解析进去的数据和过后传入的参数统一就放过后端开发一码，
要么“哼”（前端小姐姐直问后端开发时的表情自行脑补）（狗头）
居然和参数一样，看来不能找后盾撕逼了。（无聊，没有氛围）哈哈哈。
那么问题到底在哪里
仔细的童鞋应想到，如果后盾给你的小程序码数据没问题的状况下，只有这个数据正确应用了那么问题必定不存在哈！
那么就一步步证实下吧！没方法，线上环境打 log 也看不到，测试问题就间接 toast 或者间接输入数据搞吧，谁让开发工具模仿实在环境还是有问题呢？
间接展现，暴力吧！
还有个中央我排错解决了，就是转图片的时候每次生成一个临时文件，名称居然一样，为了排除插件性能中自身的问题我加上了工夫戳，我可不想来一步一个标记，而后审核提交线上后测试，都是工夫啊，把有可能出问题的中央给他全堵死了。
感触下测试这个问题必须线上环境的烦躁。最初一次审核居然是中午 1:17 鹅厂不是强制 6 点上班么？
<img src=”https://gitee.com/stivepeim/img4mk/raw/master/20210621151306.png” style=”zoom:50%;” />
结语
能够释怀的扫码到指定商品了。想不想晓得这个商品是线上哪个？
<img src=”https://gitee.com/stivepeim/img4mk/raw/master/20210621151719.png” style=”zoom:25%;” />
其实下面遇到的问题就纯属是坑，失常的应用过程中环境简单，但咱们都有一颗解决 bug 的心不是么？
在下面的批改中我其实只是做了数据参数的确认和生成后的代码优化和线上的确认而已。然而到底是优化小程序解析数据失效了还是增加临时文件工夫戳失效的还真没确认，不过临时对我来说不重要，前面有工夫接着这个问题持续玩。仔细的童鞋也能够帮我验证下哈！
不怕脱发的 大粽子，没有一扇门能始终挡住一个执着的人。加油。
