全网发布通过审核。
1
第一次遇到的坑，是客户支付时，正好进来个电话，支付成功了，但是我们这边没有收到返回信息，因为当时网断了。
解决方案：使用云函数异步接收订单结果。
2
不料又遇到一个坑，突然出现两笔一模一样的订单号。两笔都标记成功了，但其实只有一笔支付成功。
头一次出现这情况，没有复现。
解决方案：把防止二次提交优化一下，做得更加严谨，并且支付的异步回调函数获取订单改成倒序，按订单号查询最新的一条，做二次防范。
3
以为这样应该没问题了，哪曾想，又出问题了，有一笔订单没支付成功，但是被标记成功了。原因是 wx.requestPayment 这个接口的 success 只是通信成功，而不是支付成功（文档害人，注释上写支付成功）。
最终解决方案总结：
- 小程序端发起支付，创建一个未支付订单；
- 通信成功后跳转到支付结果页，这一步前端不做 status 的修改，而是让回调的云函数根据支付结果去修改订单 status；
- 跳转到支付结果页先检查订单 status，如果是未支付状态，则请求 CloudPay.queryOrder 接口，查询支付结果，修改订单 status。
这样就把修改订单 status 的操作统一交给后端，前端只负责展示。这个流程也符合文档里给出的最佳实践。
今天带大娃去常规涂氟，顺便二娃也带去检查，发现门牙缝隙有点蛀了。
本来想涂氟和窝沟封闭，但是二娃太抗拒，就放弃了。医生说要绑手脚，我觉得太没人性，还是等过段时间再说吧。
出了问题，就会突然有一堆人跳出来指点江山。
不给人制造噪音，亦不被噪音干扰。
今天带大娃去参加健身房的私教会员年中答谢会。
真没想到健身房还有搞这种活动，挺不错。营销是营销，但重点还是能让人感受到温度。而且人家推的也确实诚意，除了抽出二十几个奖项，泳课也直降五折。本来上周想给娃报泳课，我的教练建议我活动这天再看，果然省了一笔。
教头真是喝高了。喝高了好，主持这种活动，不就是要这种飙嗓子的效果吗？
健身房能做到这氛围这口碑，实属不易。君不见整个健身行业都名声败坏了吗？这一家感觉是给健身行业长脸了。
这个问题主要是体现在微信结算技术服务费的时候，需要开 6 个点的增值税发票，小规模公司只能开 1 个点的发票。
我们讨论下来是这样：先注册小规模，后续达到了申请技术服务费的标准，先用 1 个点的发票尝试，如果申请不成功，再升级成一般纳税人去申请服务费。
这样比较节约前期的记账成本，一般纳税人的记账费比小规模高一倍，但其实前期没必要注册一般纳税人，因为没收入或者收入很少。从小规模升级成一般纳税人只要几天时间，当月生效。
意外发现微信支付服务商能额外获得一笔收益。
例如商家提现手续费是 0.6%，那支付服务商可以获得 (0.6-0.2)% 的收益，但是需要开增值税发票。
那么微信生态的 saas，就算不收商家的年费，生存也不是问题。
只是这个返利补贴有一定期限，明年或者过几年可能就没有了。
《秋气》是毕业前最后一学期，以及毕业后半年里经历的一些事情。
《浆糊》是职涯。浆糊是一种糊状物，像液体又似固体。恰似浆糊一样的江湖，无以名状。
《边路》是创业。名门走主路，啥都没有的当然只能走边路。主路需要大军，边路只需几杆鸟枪。
早上起来跟合伙人聊了下合伙协议，主要是股份分配、收益分配。
聊下来挺顺利。接下去是注册一家新公司。
今天理顺了“订单核销”的逻辑，但是在“取消订单”的逻辑上卡了下。
想起前段时间看到的一个新闻，是关于打车的，司机开了几十公里到了目的地，结果乘客取消了订单。
这是一个很尴尬的场景。假如店主正在配送途中，这时顾客取消了订单，是不是也很蛋疼。
看到一篇文章《电商技术解密之取消订单》，没想到比我考虑的还要复杂，我暂时还只是单个商品的订单。
后面想明白了，顾客操作取消订单后，订单状态变成“订单取消中”，店主端将收到一个售后单，状态是“订单取消 (待确认)”，如果店主同意，则取消成功，如果不同意，则取消失败。
浙公网安备 33010602001796号