点进了项目的 Issues 页，存粹的视觉冲击和信息震惊了我半年

非常不理解为什么现在装修都想着一次性搞好 2.5G 或 10G 网络设备。难道装修完接下来十来年就再也不换不升级网络设备了？

提前把七类起的网线埋好，再铺一下光纤（战一下光纤今后可能会普及的渺茫未来），然后随便买个几十百来块的 1G 交换机装上去，先给家里组好个 1G 内网，这个是主网

剩下 10G 网这种东西，就目前需求来看，主要是在电脑和 nas 之间才会有 10G 网的需求，那 lz 就别买交 10G 换机，直接将电脑和 nas 直连。成本也极低，淘宝一张拆机 10G 网卡也就六七十，买个三张分别插到 nas 和 lz 的两台电脑上，然后两台电脑通过网线 or 光纤直连到 nas 上（连接线材取决于你买的是光口还是电口网卡），然后手动配置下不同网段的 ip 后，nas 和电脑间就是独立于 1G 网的 10G 局域网了，区别就是这个 10G 网没有交换机。我现在家里的网络就是这样的，电脑和 nas 间 10G 直连，wifi 和其他所有设备都是连着 1G 局域网

然后等过几年 2.5G ，10G 的网络设备便宜了，就逐步替换掉 1G 局域网的设备，慢慢把网络升级到 2.5G 和 10G 。原本旧的 10G 网自己看情况保不保留

@hzzzzzp94 你还是经历的网速变化的时代少了

也就不到十年，十年前，在那个 100M 才刚普及的时候，你说要用超五类，六类网线组 1Gbps 的局域网，会得到网上一堆懂哥教育你说 1G 今后只能上光纤； 1G 的设备太贵；想象不到怎么有人用电口跑 1G 之类的。然后过了不到几年吧，这些董哥们就被打脸了。

然后 1G 普及开来，就轮到了 10G 了，一模一样的话术又来一遍：10G 还不上光纤？ 10G 怎么可能用电口跑？ 10G 的设备太贵了买不起；根本想象不到怎样的需求会需要 10G 的带宽巴拉巴拉。然后现在已经没人会说组个万兆必须上光纤了


现在话题又轮到 10G 以上的带宽了。同样的争端和历史一遍遍上演。我是不相信光纤和各种光设备在今后会在普通家庭局域网内普及的。哪怕是到了 40G 这个宽带，十来年后依旧是电口为主

我自己装修会选至少七类线起，绝不做任何妥协，然后顺便再提前铺好光纤

别说六类也能跑万兆，装修一次是要管十几年的。我坚信以目前对网速需求的增长，十来年后 10G 以上的网速需求会非常普遍。六类线你再怎么说也不可能跑 40G ，而七类线是能跑 40G 的

也别说什么等过了 10G 就直接上光纤了，就目前光纤的普及速度，哪怕再过 20 年我都不觉得光纤会在普通家庭内普及开来

@gitrebase emmm 虽然是个比较复杂的问题，但就结果来说 redis 相关的操作最终放入 repository 层的情况会更多。因为即便是用 Redis ，很多时候和用 mysql 的目的也是一样的——都是为了读写 Entity 。涉及到 Entity 的读取恢复的话，那就是 repository 的职责了。

@BeautifulSoap "要么就是数据库操作太简单一行 sql 结束" 这里说错了，不是数据操作太简单，而是业务太简单，涉及不到多数据的互动保存，或者干脆就是把很多本应放入业务逻辑层的逻辑给塞进 repository 这一层里了。

事务塞 context 里，然后从 context 取事务。所有方法不管你有没有用到，总之规定好第一个参数就默认是 ctx context.Context ，算是 go 写业务的标准做法了

至于在哪里开启事务，我喜欢在相关复杂业务逻辑起始的地方，比如 doamin service 里，然后同时 rollback 也是在 domain service （当然 tx 这东西肯定要包装抽象一下的不能直接用）。至于别人为什么不开事务，要么就是数据库操作太简单一行 sql 结束，要么就是根本没考虑倒需要在业务层用事务（以我经验，大部分人属于后者，就是纯粹的没有项目经验想不到那一层）

> 顺带问个 gorm 的问题，你们用 gorm 的话，还会把它再封装一层 dao 么，还是直接放到业务逻辑部分的代码中？

repository 了解下，想好好写业务的话直接的数据库操作之类的不应该放到 doamin 层

邮政又不属于市场竞争的一环

建议了解下当年（说真的也没那么多年前），看看当年邮政是怎么千方百计垄断快递行业，差点把整个中国快递业给整死的。指望邮政还不如指望太阳从西边出来

用 wire 或 dig 这种 di 库

@body007 真摸索的话你就会发现 Directory Opus 的各种功能之丰富、全能、复杂超出想象。从内置各种压缩包无缝整合、文件切块复原功能、内置 everything 、文件夹内文件去重、文件夹同步、强大的批量重命名（还能写脚本）等等。而且对于更复杂点的需求，它还内置脚本引擎，甚至还能像 VB 那样自己画对话框窗口写代码（目前唯一的槽点就是内置的脚本引擎是 VBScript 和 JScript ，作为一个老古董 JS 引擎后者代码写起来比较难受，要是能再加个支持 ES6 的新 JS 引擎就好了）

不用问了，视频里推荐的 Directory Opus 就是目前 windows 下最强大最好用的第三方资源管理器，没有之一
用过就知道它和其他资源管理器根本不是同一个等级的东西。唯一缺点就是比较贵

自从七八年前用上 Directory Opus ，我就再也没有碰过 windows 自带的资源管理器了。用了 windows 11 快一年了，我到现在都不知道 windows 11 自带的资源管理器到底长什么样

自从不自己做饭之后，每个月伙食费暴涨倒 7w+日元每个月。之前是每个月 4w+，低的时候甚至能挑战下 3w+。

就现在这种商家一块多发全国的快递价，还要求快递员送货上门说真的我是真觉得过分的了。哪怕是站在消费者角度，我都觉得这新规对于促进快递行业发展没有任何良性作用的。
真想送上门，目前就有办法：让商家发顺丰或京东。你多花的那十来块钱就是真正享受到这种服务需要的价格。在一块多发全国的客观现实下，讲任何新规之类的都没什么用。送上门成本要么快递公司贴本承担，要么就是压榨快递员来承担

一方面嘲讽自己是帕鲁，另一方面又心安理得的去压榨另一群帕鲁

谷歌相册然后 syncthing 实时备份一份到 nas

先问自己有没有用手机 suica ，id ，quick pay 等等这种日本 nfc 支付的需求(felica)

没有：因为国内手机系统内置的谷歌框架是残废，如果对国外 app 依赖不高（比如接受收不到大多国外 app 的 fcm 推送通知，接受部分谷歌服务无法正常使用），那么国内手机随便买。
如果想要正常使用海外服务，选择能 root ，解锁，最好能刷海外 rom 的手机（小米，一加）

有 felica 需求： 接不接受再花 4 ，5 万买个智能手表。不接受，lz 只能选择买在日本本土发售的手机了。小米，oppo 日本也有发售，不过高性能性价比并不高。
接受买手表，花 4,5 万买个日版 galaxy watch 6 或 pixel watch ，它们内置 felica ，这样 nfc 支付交给手机手表就行了不用手机了。选手机就可以参考第一个对 felica 没需求的条件来买

看描述就是飞蚊症啊，实在不放心你可以换更好的医院要求做更多检查，比如超声波甚至核磁共振。但结果大概率结果是没任何问题

@Seria 剃毛毛不推荐上剃须刀。要么用脱毛膏，要么用专剃体毛的剃须刀然后配合激光脱毛仪，这样长出来的毛毛就不扎人了

考虑安卓的话可以试试海外版的一加 12
双 sim+1 esim 的三卡双待