@lqw3030 #12 正常逻辑来，消费者在食堂消费 60w 元，食堂开票开给消费者的，为什么要开给你支付渠道公司，你支付渠道公司只收取了食堂 6000 元的技术服务费，所以食堂只需要开 6000 的发票给你就可以了。
为什么食堂会给你开 60w 的成本票，实际上是因为消费者没要求开票，且钱在你手里，想拿钱就那发票来，他只能就范

@lqw3030 #3 正规的是有支付牌照的，譬如拉卡拉是有支付许可证的，收钱宝是阿里巴巴的也是有的。你说的“XXX 收钱”具体是哪个，你去查他官网有支付许可的都会挂在网站上的

代收代结算属于“二清”，本质上是违法的，步骤 2 提现到公户，属于收入需要报税，步骤 3 转账给食堂公户又需要发票或者合同。

你的场景不涉及多租户，所以可以简单一点。
你们可以让食堂自己注册一个微信支付的商户号，收款方式全部换成食堂的，钱直接进他们对公账户里。

如果涉及多租户的场景，可以用电商收付通的产品，参考
https://pay.weixin.qq.com/static/partner_ability/business_payment.shtml

@PbCopy111 op 似乎就是看不到支付宝惠出境，算了，人家就是想自己折腾银行卡

@Elix 他的东西都是溢价老高的，他的理念就是要送就要送性价比极低的东西。100 块买一卷卫生纸，在厕所啊哈哈哈

哦，苹果的这个 icloud 备份还有 up 专门做了测试和教程，就为了讲清楚备忘录的备份逻辑，有很多人备忘录被 icloud 清空丢失了所有的笔记。ios 一边是简洁让用户无需思考，另一边是复杂的机制，复杂到需要专门出个视频来教你如何用 icloud 备份备忘录

这种写个熔断策略很难吗？ 为什么所有云厂商统一不提供这种功能？

@kokerkov php 的 还有一个 phpStudy ，这种软件都声明了仅用于学习，不要在服务器上使用。 因为本来你服务器好好的，他上面带个 ftp 版本有漏洞，给人提权就黑进来了。op 这种也是类似的，集成的软件还挺多，哪个软件万一有个漏洞的话，就不好说了

trade in 现场换新机，过几天退货的路子听说是已经堵住了，你过几天退货的时候他们会从后台把你之前的机器还给你。 按规定你的机器应该是要在店铺保留一段时间的，但实际上以前操作都是第二天就寄走了，所以产生了之前的那种操作，现在是按流程来了，你的机器保留在店里了

@meters #40 没有抢到码，试用版体验了一下，
1. 发现发音是机器生成的机械的读音，要是能更像真人的读音就好了，
2. 另外感觉 UI 可以再简洁一点，图 3 顶部是问题，中间是生成范文，下面又是词汇和短语，在往下还有例句，上来就给我吓跑了
3. 可能不适合我这种基础比较差的

这样子可以不？
SELECT
COUNT( 1 ) AS "新参保人数"
FROM
AC02_TEMP AS A
LEFT JOIN ( SELECT B.AAC001 AS TID FROM AC02_TEMP AS B WHERE B.AAC030 < '2018-01-01 00:00:00' ) AS t0 ON t0.AAC001 = A.AAC001
WHERE
A.AAB301 IN ( SELECT AAB301 FROM AA26 WHERE AAA148 = '130800' )
AND A.AAE200 = '41'
AND A.AAC031 = '1'
AND A.AAC030 >= '2018-01-01 00:00:00'
AND t0.TID IS NULL

没有了，都用过了

13pro 意外摔了一下，屏幕没摔坏，但是经常没有移动网络，直接信号全空，要切换飞行模式才能有信号。 我猜可能是摔的时候双层主板焊接松了。预约天才吧运行检测程序，说天线检测是通过的，但是有一个 sim 卡的检测一直卡死，返厂维修，1 周半拿回手机。
主板换了，摄像头也换了，电池换了健康 100%，之前电池是 89%。 序列号是官换机的序列号了

备用机建议不要拿了，64G 的 XR ，损坏赔款的钱可以买一个二手 XR 了。 怕什么来什么，小心翼翼使用备用机一周了，周末从裤子口袋滑出，小区出新地上很多碎石头，xr 屏幕在地上次拉了一条划痕，超级深，深的心疼的那种，以为要赔 1200 了，结果天才吧验收的时候说，划痕不算碎屏，屏幕碎了才要赔。

实际生产中严格按照第三范式设计的数据库比较少
生产上我觉得唯一索引还是非常非常有必要的，靠代码层面无法杜绝脏数据进去，还是得靠唯一索引

小程序之间跳转用户信息不同步强制退出机制吧，其实也就是一个 if 的事情，我猜可能是两边账号绑定的手机号不一致，或者某个小程序很早就用了，历史账号数据不完整之类的问题，这种问题得反馈给开发，调试后修复脏数据才能正常，但这么大的企业，我们普通人怎么对接到开发帮我们找一个账号的数据错误呢

抓包直接 post

其实是平台报错有歧义，非法参数到底是 token 、secret 验证失败，还是请求 api 的参数有问题？ 我认为做接口一定要报错报清楚了，什么参数有问题就说哪个参数有问题，并且给出解决方案是最好的报错。 譬如这边如果报错提示“验签失败，请检查 token 、appid 、secret”。 如果是上报的某个参数真的有问题，举个例子如果是 age 参数，后台校验 age 必须为 int ，且必须 0-100 之间，既然校验这里报错了，就应该提示“age 参数非法，请输入 0-100 之间的数字”。

怕就怕接口文档不写清楚，报错提示也不模模糊糊，这种接口最难对了

还可以这样操作？ 我一直以为哪个 id 从 appleStore 下载游戏的，就必须哪个 id 付款，否则就会报错呢