@Narcissu5 "《黑客与画家》里面专门有一章讲为什么要用纯文本"，没看过这书，这是直接否定对样式的真实需求吗？

你说的最大好处是只记录内容不规定样式（列表项/表格单元格/链接等等内容就是各种格式了，你说的应该是指样式），不规定，是分离内容和样式而已，没错，方便在不需要编辑内容的情况下随意调整样式。主要是限制了元素的多样性，标题只有 6 级(记得好像是)，所有 1 级标题样式统一，不需要那么灵活，对于所有的一级标题，极少需要针对某些个一级标题整出花来差异化表达出额外的信息)，合作者的样式再难苟同，内容格式正确，到我这来按照我喜欢的样式展示，依旧很好看。

然后非常重要的是输入方式，我不知道 word 有没有特殊的指令/宏之类的将当前输入的元素的样式设置为一级标题，在我认知中只能先输入内容，然后由键盘切换到鼠标操作...在键盘和鼠标中切换，对于大脑来说注意挪动手掌位置，是一种很重的消耗，尤其是需要频繁操作，严重影响心流，这才是主要的一大痛点吧。markdown 输入起来确实爽多了，至少常见的大部分元素是覆盖了，当然我指的是在所见即所得的编辑器下的。

@hhharuka 需要"约定优于配置"！

@sn0wdr1am 问题是，哪里出了问题，会全球和国内，环境都恶化成这样，有没有可能避免，如何避免，没人在乎这个问题似的😄

个人觉得 var 、val 、fun 这类真的鸡肋，我们的代码中不需要充斥着这些"冗余"信息，编程语言就可以理解为一种 DSL ，语法体现在那了。

我们需要的是对齐，"var : Type"这种也不是不可以接受，最好还是 IDE 支持：
1. 值/表达式.var 然后自动识别类型，光标先选中并定位在变量，然后再选中定位到类型，可以按 Tap 之类的跳过不需要修改的
2. 选中一组变量，按快捷键自动对齐变量名

还有，像访问修饰符，大多数情况下属性是需要封装起来的，默认应该是 private 级别，而不是 package 级别，这类默认项是值得优化的。

@kandaakihito 兄弟我不是针对你啊，那么问题来了，为什么不是让需求三思而后行，反倒让开发团队反复做无用功呢？(我不信所有人都只是拿钱办事的态度)。我不知道 Mybatis 是否还停留在 SQL 和接口分离的阶段，但那种改个点要同时打开多个文件的操作是真的恶心，整天低耦合低耦合，是真不知道高内聚吗，如果说要统一审查 SQL 之类的，那不应该额外写个 IDE 插件之类的搜集吗？另外有一点，我很反感那些以为写 SQL 很高大上，很有成就感的行为，毕竟代码是要讲究可维护性的。

个人思考：学习是个探索（不断完善一个图，最好以一个图的形式展开）的过程，对于错误的路径应该及时关闭，不必要的信息会干扰会造成负担需要及时移除，毕竟"当前上下文的容量"是有限的，因此当要探索(深入理解一些个概念时)，应该使用 hover ，弹窗的形式展示新的内容，并在确定不是想要的内容时方便快捷地丢弃，例如鼠标移出。

@BiChengfei 哈哈，人这么多，你猜猜为什么上层不卷，你让上层流动性高起来你看卷不卷。不要无视核心矛盾，叛徒该死但本质问题不解决叛徒不会消失的。

@lixintcwdsg 内存占用方面（毕竟阻塞 /等待，注册事件回调后方法就返回了，响应的调用栈（的栈帧链）就回收了，回调时再重新算）还是明显 eventloop 这种香的，就是不好调试，然而对于一些经过长时间运行测试，很稳定的逻辑，例如 Netty 自身的 I/O 处理的，没事，本身更多关注业务逻辑，调试也只会调试业务逻辑的（问题基本都处在这），所以 Netty 的线程模型应该不会变，上下文切换这块不得而知。
而处理业务逻辑部分，开启虚拟线程的边界，用虚拟线程 carry 更合适，不冲突的，与其说平替，不如说互补吧

@dreamlike 上面第二段的切换值得的是阻塞的时候（目前是只包括基于 JUC 的同步器的以及网络 I/O 的吧）。类似 kt corotinue 等无栈（例如基于方法参数传递状态机的？）能不能做到这种 Hook 我也不知道，我想表达的是，JDK 应该不会支持，毕竟每次 resume 就跟新的一次方法调用一样调用链都丢了，调试困难。

@dreamlike 虚拟线程核心就是提供一个替代线程的模型吧（线程是“通用”操作系统的任务承载体，这个调度机制要支持很多特性包括一些统计，而这其中大部分都是不需要的就是太重了，除了带来不必要的元数据占用内存空间，还有这些数据的保存变更逻辑就是上下文切换，而且涉及影响其他进程还需要陷入内核模式执行），线程池解决占多余内存的问题，阻塞会导致并行度丢失于是需要引入并行度补偿机制，但在阻塞密集的时候又创建了太多 worker thread 又趋近于 thread per task 了，解决办法就是（在需要进行上下文切换的地方，就是阻塞 /等待，内在逻辑也是注册回调条件成熟唤醒）用更加轻量级的上下文切换替代线程的，就是虚拟线程的，或者额外搞一种支持注册回调并会 poll 唤醒的机制直接摊牌不阻塞了拆成有依赖关系的多个分支任务（上下文丢失除非又保存，当然可以做得比较灵活在调试时才开启，真实性能差距不得而知）。
JDK 中应该只会在确定当前任务的承载体是虚拟线程时在切换的时候才会进行虚拟线程的上下文切换（而不是线程的上下文切换）。问题来了，kt corotinue 中的代码，能有阻塞（真正意义上的，能调试的那种）的逻辑吗，如果有，发生的上下文切换，还是线程的上下文切换吧。

@Richared 上次回复是 5 天前了呀！当然你回我了就无所谓了。后面的感觉辩下去没意义了，就这样吧

@Richared 兄弟，你要吐槽的到底啥呀？你不回我的话我是不是就可以理解为是想装死了？

@Richared 这是你的需求是吧，那你要吐槽的点呢？是无法实现只提取必要的属性节点的吧？
如果是。把查询和命令区分开来，这种查询使用 EntityGraph 应该能解决才对，能说说怎么无法实现你的点在哪吗？当然实际开发中会使用 Spring ，结合其提供的 @EntityGraph 使用更方便；
鉴于你的查询条件单纯用 ById ，像 CriteriaQuery 、结合 QueryDSL 就没必要提了，如果不要求将结果组装成实体类型的，要返回 Projection 的话，无论 JPA(Hibernate)还是 Spring 也都有提供相关的支持的。

@Richared 嗯，然后重点呢？“包括你要吐槽的点，是实现不了，还是按你们的理解只能如何实现怎么个麻烦法，还是怎么个不优雅法。”

@Richared 其实你大可直接一点，说说什么业务才不算你们口中的 demo 项目的，然后贴具体涉及的实体（关系描述就行），以及需要搞定的需求。包括你要吐槽的点，是实现不了，还是按你们的理解只能如何实现怎么个麻烦法，还是怎么个不优雅法。

适配器

只能说 talk is cheap 了

大佬们都直接使用 wordpress 搭建的吗