这是否需要搞万兆架构才能吃透着带宽？

我不信能有无穷的 ip 资源，稍微用 php 中用 redis 记录一个 ip 如果一分钟内访问了两次 404 路径，立马在入口最开始的地方拦截返回 404 。拉黑的 ip 放一块儿定期拉出来写入 fail2ban 。当然还可以人为或代码判断，直接对某段 ip 拉闸。期待 op 后续更新

感觉已是闷声发大财的语言

想不到啊，一个简单的问题炸起这么大的讨论。看来经典面试题目“说出你对 get 和 post 请求的理解"还是不能撤掉

2023 PHPer 路在何方？

nodejs 方案不选用的理由+1 ？

我这台 6 年前的 y50-70 搞黑苹果，用得正爽

顺手分享下今天遇到的一个问题，wps 中 excel 导出网页不能选择单个 sheet 导出，导出所有 sheet 的网页会使用框架，然后无法在 chrome 打开

测试一下喇叭有无破音，有朋友的 mbp 尝试了一下喇叭，发现大声一点就有一边的喇叭是破音的。

小孩子不做选择，开会用 14 ，坐下来就用 16 ？

没那么严重吧，平时来回切去 note 或者电话本搬一些发票信息，都没试过重启啊，6s 钉子户

所以，酒店系统能恰个外包？

所谓的转，会有明显感觉？感觉负责事情多的后端，慢慢就变成了产品经理？

之前参与过一次讨论，确实不只是 Ramdom 那么简单。主要是不能确定抽奖总次数（总人数）。
一般简单的需求只是提出了中奖概率：一等奖中奖率 1%，二等 3%，三等 5%，为了方便讨论，姑且再简单化每个奖项奖品数量为 1 。
然后大多数人一上来的写法就是 random1~100 ，然后得出指定的一个或者多个的数，来做中奖判断。
实际上这种简单模型，只遵循了理论上的中奖率，没有符合到实际需求。因为中奖变得“先到先得”更为重要了（可以写个模拟抽奖 demo 测试一下），但实际上一场抽奖活动更多的是希望吸引更多的人流，并不想活动开了半天大奖全部抽完。
所以当时我盲猜两种做法：1 极度调低实际的中奖率，配合活动结束时间稍微调整让奖品都能送出； 2 也是要配合活动时间定时定量动态调整奖品中奖率。