背景： {代码...} 分享一个文件缓存类 {代码...} 使用方法 {代码...}

消息队列：解耦、削峰、异步这3大场景你可以思考一下用不用的到，有没有必要用

谢谢各位指点，之前已经解决了，采用了异步回调，流程为：商户提交订单->平台->供货商系统供货商充值回调->平台->商户考虑到平台方需求，回调未做队列处理

成熟的方案，就选择上面大佬的回答，想自己锻炼锻炼就写适配器，写策略。但如果投入生产环境，还请不要过度自信呦o(￣︶￣)o

思路倒是可以，能想到抽象已经很好了，但是……这不就应该用简单的适配器模式吗？现在程序员都不学设计模式了么……你依赖的第三方服务都应该抽象成更高一层的东西，不要侵入业务代码，否则一旦改起来就像你说的，会非常痛苦，尤其 PHP 还是个弱类型的。

收到支付的回调后, 不要直接去更新DB里订单应该 1.校验请求来源是否安全可靠 如果你的回调接口被暴露了,可能会被恶意请求,随便来个请求就把你的订单数据修改了,造成的后果,你懂得. 2.根据订单编号 查询订单是否真实存在 3.检查订单状态 是否已支付 因为回调受网络影...

两种方式会有不同的交互，所以先问一下产品怎么选 一般第三方(支付宝、微信)的回调都不回很慢的，loading两秒也就完事了，只要你们服务响应可以第一种也是没问题的 如果真对自己服务没信心，且产品经理没意见的话第二种肯定更适用你们 其实我想说要是我做这个业务我...