@dvaknheo 不了解中间件模式解决了什么问题并不是什么值得自豪的事情，建议你自己多了解一下，作出更有意义的批评。我不知道你对 Java 的敌意是哪里来的，但据我所知 http 中间件更多源自 NodeJS 社区的启发。至于 PSR6，实际上讨论过程中拒绝了来自 Doctrine 社区的更偏向 OO 更复杂的提案，PSR16 也并非取代或否定 PSR6，不知道你说的所谓故事是什么样的

至于你说把中间件接口做成两个更好，方便调试，我难以赞同。做成 before after 以后就连基本的 try catch 或有条件跳过 next 逻辑都很难做好，我也无法想象到什么场景会造成调试难易的差别

@ztmqg 还真是的，幸好没有 211 在简历上写这个，否则就被冤枉了，这个命名真是太差太容易造成误解了，一般 css 语境下的兄弟后代都是在描述 dom 树，在里面混入一个描述 css 规则嵌套的“父”真让人难受

@dvaknheo 谢谢，我还真没想到这个点，我可以做一些优化，把每次中间件调用增加的堆栈个数优化掉几个。可是没有中间件的堆栈和有中间件的堆栈并没有什么可比性。如果你能用少量的堆栈实现 psr15 中间件的串联，可以给我看一下实现我学习一下。

outline 和 mindmap 是两回事

把&叫父选择器，就算我是在筛 211 的校招也是扔了

可以冲调水温最低的是泡腾片，搅拌的话冰水都能冲开
因为不是固体好像不算冲泡，酒酿可以直接冲水当饮料喝
其次就是酸梅膏了，冰水的话底部容易留糖浆，可以常温水少量搅拌均匀然后再冰水冰块此后

@dvaknheo 你说的都挺对的，感谢你的关注

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md#use-of-custom-request-headers

TLDR：这个做法有很多优势，但已知挡不住 Flash，也容易被其他类似的技术绕过，不建议作为主要防御手段

@ben1024 各有优点，可是作为手痒要写框架的个人来说，重型的框架工程量太大了，控制规模才能有精力精雕细琢

@dvaknheo 建议看看 phptherightway 多了解了解 modern php 的成果，还有关于 di 的概念也可以多看看，php 写框架太简单很容易给人错误的认知

小孩子才做选择
mac mini 自己加内存日用主力，写代码（喜欢高分 4k5k 还接两个的预算自己加 egpu 钱）
NUC i3 不接键鼠显示器，跑跑服务什么的，便宜好用，自己换内存省下来的钱都快够了

我第一反应是这个 app 两行大字：你的 macbook 被盗了吗？ // 没有:doge:

28，后来改到 26，行距 1.05

同屏代码越少，更早对长方法产生拆分的想法，代码质量越高，不到 20 的就别说什么代码字体大了（滑稽

谈技术请说普通话

用 45w 的，开三四个 ide 和十几个窗口的 chrome 也并不掉电

---- 除了间接层数量过多的问题之外

算法是用于解决问题的一系列指令描述。他说的没问题，并不是只有教科书上的或 leetcode 里的那些才叫算法。解决“交互消费两个不同队列”这个特定问题的方法，当然是算法

an algorithm is a set of instructions, typically to solve a class of problems or perform a computation. -- Wiki

至于“代码逻辑”，我不知道什么叫代码逻辑，甚至找不到这个词对应的英文是什么，不建议使用这个模糊不清的词

@leotso 就是楼上说的孕妇效应