惨痛的事实：社会层面营销远比代码重要。 代码好那仅是个人技能，营销赚钱那才叫大能力。
写代码的人不行可以换，钱，赚不来就是赚不来。

@rainoprime850 哥们，你的咋没的？
@rainoprime850 没黑号吧。只是掉了 plus ？

@rainoprime850 哥们，你的咋没的？

@nigga 哥们你啥情况啊。？

你举出的这些所谓“漏洞“的例子才是发展方向。因为符合人类对效率的变态追求。
你大可以对支付加 100 层验证，但这只是你的一厢情愿罢了，你觉得用户会同意么？我买个口香糖要我输密码还要指纹还要人脸？？
至于漏洞会导致损失，这就更是娇柔想法罢了。。 出门还被车撞呢，哥。。
任何科技，任何产品，任何行为，甚至任何思想都会造成部分群体利益受损，但是这是发展必要的受损。

这个具体收益是啥？ 技术成本 还是 变现收益？ 开发和运维区别看你的技术选型，现在一些通用框架能跨多端的，业务不复杂成本也不高。

和小程序无关，所有登录类都有这个情况，比如我网吧登录淘宝然后走人，淘宝怎么能知道？。。
这类问题处理办法蛮多的，像酒店这个情况最简单的是在离店时你肯定要结费，收银系统触发注销 token 不就行了。

需要的。个体户就行，很简单的，一周内就能下证。

曾经和同事聊过国企各种老旧技术迭代，大家一致结论是：站在老板角度看这玩意不是刚需，无法创造立竿见影的价值。。企业目的是盈利和活下去，一个东西只能保证未来收益，等同于炒股了。。

看标题大为震撼，进去一看就公司产品正常优化一下子。这标题写的我还以为要干翻 QUIC 准备重写协议了。 老哥 UC 震惊部出来的吧？

APP 很少不是没人做，而是做了没盈利死掉了。至于采集还要资质,法律问题什么的，真的想太多了。。这种采集方式如今一抓一大把的，但 99.99%没流量最终安安静静的死掉，你想想资本烧钱都烧不出流量，随便爬爬就火了那真的是外行做梦了

你迷糊是因为你压根没搞清楚编码的逻辑。CMD 和这个编码无关他只是调用程序。编码涉及到 2 个点 A 文件保存编码 B 读取者什么编码读取。 你保存的 php 文件编码是 UTF8 ，而 php 默认也是 UTF8 读取执行的，那输出正常这有什么问题吗，CMD 在这里也只是个调用者输出也都是 php 给的。 反过来文件是 GBK ，php 还是 UTF8 读取那肯定乱了。你可以在 GBK 的 php 里改一下代码：var_dump(iconv("GBK","UTF-8",$str)) 这就正常了。

肯定是可以的。 但问题是，需求性才决定一切。
如果一个简单的架构就能解决问题，没必要实现的很复杂。

交给 DBA 去写。。。

期待头发离开故土，去看世界
期待颈椎唯心而行，无比耿直
期待手指关接受试炼，疼痛为荣
期待腰间盘突破自我，敢于追梦

这些期待
实现的可能晚一点
但是我
固执的相信
总会来的

跪舔型：
老师这个题目一看您就是老江湖了，佩服佩服，我个人觉得输出端肯定要做内存 cache 防止阻塞 IO，然后在分块后使用流并发推送防止。。。。最后在使用。。。。。 您老法眼看看可以吗？
真-程序员型：
老师，您脑子里的水没排干吗？ 什么业务需求一次输出 10w ？ 应用端一次请求 10w 设计者是大学生吗？把接口当下载机吗？ 是迅雷玩上瘾了吗？ 考虑过好好看病吗？

@shazh520 你要是这方面没经验，建议你找一些案例去实际上手体验分析原理或者找有经验同事请教，优惠业务很复杂的因为他牵扯到结算与订单系统，对于电商系统来说这相当于牵扯全部东西了，纯靠凭空想象很难有进展的。 我说的也只是整个的冰山一角，比如比较重要的一个，用户体验方面: 如果你让用户手工去填写复杂的优惠相关参数，用户肯定会疯掉的，还有更复杂的: 场景优先的互斥规则 如何实现等等。

分享一下最近给我司架构的 ERP 优惠子系统。优惠券只是优惠系统的一个功能，券只是一种发行方式，与免单，折扣，团购等其他优惠本质上是一样的，都是优惠行为即对订单内的目标进行减额或者额外赠送，只不过在使用途径上有区别而已。我司的优惠系统比较复杂而且涉及多分店跨店全部说完太长了。只是简要的说一下核心的逻辑。
首先把优惠系统的模型提出来，然后嵌入到订单系统中做成解析器，所有的优惠都会挨个分解成模型然后根据模型去通知结算系统应用。所以最重要的是提取这个模型，而不是代码层面，那些乱七八糟的 oop 之类的，模型你搞明白用什么实现都行。
我的模型主要是这几个属性: 条件。目标。行为。值。
比如满 3 减 1 优惠，条件是必须购买三份，目标是这 3 份商品，行为是减份，值是 1。
比如第二份半价，条件是购买份数大于 2，目标是第二份商品，行为是减额，值是 0.5
比如满 399 整单八折，条件是消费金额大于 399，目标是支付总额，行为是减额，直是 0.2%
再比如员工免单，条件是员工必须有免单权限，目标是支付总额，行为是减额，值是 100%
上门例子都是常见的业务中用到的，优惠子系统都可以将它们化解成模型，最终统一处理，而不需要将所有的优惠，每个都写一个逻辑。
模型大概是这个样子，你可以将模型分配一个 id,在跟踪这个 id,，给予使用次数得记录，那这个 id 就是优惠券。团购也是同理。
行为和条件可以多个组合的，实现这种复杂的优惠: 如满三减一送商品在整单 95 折最后在送免运费券和给会员积分。
手机码字太累，互斥就不说了，整体大概就是这个逻辑，你可以参考一下。