没见过有人觉得这是 tcp 的缺陷，不了解的人不敢质疑，了解的人知道咋回事。我反而觉得这个词会让人更近一步的了解 tcp 。

@oldersnail 好好学习技术就能有工作，踏踏实实干活，认真对待工作就永远不会发愁失去工作，也会有加薪的空间，这个现在称为红利，还是时代的红利，也挺讽刺的。

不是为这种代码辩解，确实专业名词太多，被迫用有限的词汇量去描述大千世界 😂 有的时候使用拼音可能要比使用了错误的单词好些。

@main1234 第 1 条 很佩服。为什么没去？

一个软件能让开发觉得自己不再重要，那这个软件在这个领域还挺成功的，毕竟它是做给你老板的，而不是给你做的。

没写过扩展，不知道是否可行。我想是否可以让桌面应用启动服务后，主动打开浏览器的一个的标签页，表现是一个连接扩展的样子，其实页面中携带了本地的端口信息，然后扩展就知道了。

老婆在百度上下载的 Chrome ，每次在搜索栏上搜索都会先发送请求到一个第三方的某个地址，然后重定向回百度搜索，搜索引擎设置正常。

使用体验上主观感觉不如 qwen 14b ，所有开源模型，每次看介绍和测评都贼厉害，真用起来就不是那么回事 。

@somebody1 多几个字段，都是 32 个 0-9 ，分别表示个、十、百、千、万位，这样每天的数量取就没有上限了。

两个线程调用 `getTask` 的场景，如果使用 if ，其中一个线程会消费掉队列中的数据，接着第二个线程会在 wait 处被唤醒，继续向下执行，错误地调用 `queue.remove()`

@wxw752 Netty 的 buffer 是基于计数器来决定是否释放的，每个 handler 有义务对不再使用的 buffer 做减少引用的操作，继承了 SimpleChannelInboundHandler 的话会自动执行一次减少引用的行为，在 handler 链的末端会再次做一次减少引用的动作，如果 handler 链执行完，buffer 的引用计数为 0 就会被释放，所以有些业务需要会通过 ReferenceCountUtil.retain() 增加引用计数，避免 buffer 被释放，不小心会导致 buffer 泄露，实际上在 netty 中已经内置了泄露分析的工具，可以考虑在测试环境添加 io.netty.leakDetectionLevel 参数来分析是否存在 buffer 泄露。

as*hole

@XCFOX 中肯

技术上没有什么东西能同时满足解决复杂的问题并保持简洁，如果有，那只能说明问题不够复杂。就像 JPA/Hibernate 或者 Spring Framework ，了解的多才有信心写得少。

@Kholin 变的有点多，hacker 不多，news 更少。