@june4
我认为那位朋友没说错，HTML / CSS / JS 就是不适合写 UI 。而且理由人家也说的很清楚了，UI 应该以组件为单位，但是现实里我们写一个 UI 组件却需要再三种语言里切换（而且是三种思路完全不同的语言），这会带来巨大的心智负担。

最早说 Web 这套逻辑适合开发 UI 的，是因为 UI 界有个观点，认为“标记型语言”是最适合描述 UI 的，而 Html 刚好是标记型语言。所以 UI 界才开始注意到 web 这个东西的 UI 潜力。但是偏偏 CSS 这个东西，它不是为 UI 设计的，它是为排版设计的，排版的需求和 UI 的需求，只能说有交集，不能说完全匹配，所以你如果用 CSS 去做 UI 的话，总会被 CSS 里为排版设计但不是为了 UI 设计的那部分特性干扰。很多人对 CSS 的畏惧就来自于此，这东西并不是为 UI 开发的。

相比而言，性能反而不是最重要的问题，毕竟不是所有领域的 UI 都对性能有较高要求。

HTML / CSS / JS 这套，从 2000 年左右开始，一直到现在，不断变革，不断翻来覆去大家吵架，已经 20 年了，大家还是没争吵出个最佳实践来。而争吵的业务在什么领域呢？就是 UI 。单纯的没有交互的排版页面大家反而没争议。这恰恰说明了，这套东西基础层面上有问题，以至于大家反复的在实践上翻烧饼。这个问题，其实就是基于排版设计的系统，和基于 UI 设计的系统之间的阻尼。

jellyfin 装在 NAS 服务器上有一个重要作用是将视频转码，降低码率后再播放的，楼主你直接从 NAS 上取原版的视频，需要很高的上行带宽，不是所有人的家庭网络都有你那么好的条件的

你们对钉钉有什么幻想？钉钉这玩意是给老板开发的，老板的需求是什么？当然是无死角监控你们这帮打工的。

上面有人居然开钉钉群摸鱼吹水？你们胆子真大啊，我现在是能不往钉钉发的消息就尽量不往钉钉发。人家可是专门帮助老板来管你们的，你们居然敢在钉钉群摸鱼？

还有上面那个说飞书的，飞书的定位和钉钉是类似的，只不过作为后起之秀，暂时没那么恶心而已，用飞书的也自己小心

@PolarisY 非常感谢给出最佳实践方案

@CodeCodeStudy
rust 是单独一级的，C++都比不上，C++你不用特别精通，至少能写出 1+1 = 2 来； rust 如果你上手不能理解它那套思路的话，对不起 1+1=2 都编译不过去

@wxw752
1.没有写过这个 scope
2.后面发现。还真是这个原因。


@miaotaizi
按照 maven 官方文档的说法，子模块的依赖是会传导进父模块的，所以父模块肯定知道子模块的依赖


@PolarisY
感谢你的这个命令，我是思维定式了，被困在 IDEA 这个 IDE 里提供的 maven help 提供的信息中。正是这个命令，让我发现了一件有趣的事情：
+- (com.squareup.okhttp3:okhttp:jar:3.14.9:compile - version managed from 3.12.13; omitted for duplicate)
明明，lib1 依赖的 okhttp 是 3.12.13 ，但是运行 mvn dependency:tree 后，显示 compile 时的依赖却是 3.14.9 。很显然，我原本以为这个依赖是 lib1 造成的，现在看 lib1 虽然要引用依 okhttp ，但是版本却不是它指定的。
最后我顺藤摸瓜的找到了一个命令
mvn help:effective-pom -Dverbose
这个命令指出，module A 引用的另外一个 lib ，这个 lib 中，指定了 okhttp:jar:3.14.9 ，根据 maven 依赖冲突调解路径最近原则，maven 实际用了这个版本。

所以，module B 不需要排除依赖，直接在 module A 中强制指定 okhttp 为 4.x ，根据路径最近原则，这个版本会强行覆盖 module B 中的 okhttp 依赖，于是问题终于解决了

备份方案？你正文里一个备份都没有

前端不管 CSS 的话，和后端思路没区别。问题就在于前端有 CSS 这个深坑

只要你有钱买 CDN 就行，静态内容分发技术是很成熟的

视频编解码技术一直在进步，GIF 一直停在原地，现在视频已经是兼容性赶上了，比 gif 压缩比更好，更清晰。那还要 gif 何用

你这酒但凡有一次失误，混进点杂醇进去，把人喝伤喝死，就准备坐牢吧，这可是有现实案例的，自酿酒最大的问题就是控制不了质量

@dylanqqt 朋友，十个人纯后端的项目真不能算大的，国外推荐开始考虑微服务的时间点，基本都是你已经有几十个不同功能开发小组的时候，而不是十几个人的时候。
当然，你这个时间点可以开始考虑转微服务，只是我觉得此时收益和付出的代价比还是不够。

微服务其实是一个“在到了一定条件下不得不选”的选择，而不是一个“更好的”选择。我觉得所有人在决定上微服务前，都得想清楚这个区别

@dylanqqt 虽然那位说上千人有点夸张了。但是你这十多个人维护的几十个服务，也能叫业务规模大？

老外有个暴论：当你的团队人数用一盒披萨就能喂饱的时候，你根本不需要微服务这东西。

微服务一定要系统足够庞大，庞大到不拆分几乎无法维护的时候，才会有意义——相对微服务带来的那些问题：运维麻烦，各数据分散在不同的存储中，报表困难。

另外和大家想的不一样的是，不要觉得微服务上了，就真能各团队独立，这其实是个幻觉，现实是大概率你把你的服务改了，一个依赖你的服务挂了，这才是普遍现象。

微服务不是灵丹妙药。

对个人来说，Go 非常好，资源占用少，能省下不少服务器费用。
对企业来说，Go 省下的服务器费用不注意抵消 Go 开发人员工资远比 Java 开发人员高，还难找的尴尬。

所以用哪种语言只取决于你自己的身份

@nyxsonsleep
我没有指明 A 、C 分别在两个内网中？？？？？
======
A 在甲地网络，C 在乙地网络，都没有公网 ipv4 ，这不是双方在各自的内网里，又是什么意思呢？


“另外我已经明确说明“B 只允许 A 访问。”，为什么这种情况下能打洞？”

C 和 A 分别在不同的内网里，它们要先连起来，所以才说尝试打洞