常规定制柜的那种板材的隔音如二楼所述，等同于开放空间，但是可以往两层衣柜之间增加一个隔音薄墙，成本比较高，但节省空间，也有比较好的隔音效果。

您是否在找：JBang

@DavZhn 你好，我之前了解到的情况是网号会公开给应用，你这个有依据吗？

@ldapadmin #22

https://i.imgur.com/HgPMVty.png

销售常用话术：线上款和线下款是不同产线，线上款质量没有保障。。。

我的经验是 NB 的品牌热销的型号线上线下是一个价，线下因为可能因为本地商铺有国补可能还比线上方便点。但是某些品牌线下款基本上就是两三年前的线上款，还要卖很高的价格，感觉就是给不接触网络的大爷大妈出货用的。

1k 内的浴室柜只能线下找，一米的陶瓷盆+木柜体成本纯物料成本都中百了，线上买的话加上运费这个预算只能买最低端的，还不如去本地线下碰碰运气。

智能马桶我感觉京东京造的性价比无敌。

不太理解马桶扣扣索索，床垫这么大方是啥思路。。。床垫要试睡就只有线下，否则网上看其实看不出来床垫本身的体验，人体也会自己适应的，刚开始睡有点差异过久了就习惯了。两三千就可以买到品牌真材实料的了。

网号和监听无关，但是用了之后会有一些其他的问题

1. 本来大多数 app 是通过手机号间接实名认证的，换成网号之后就相当于直接实名了，封号变成了封人；
2. 网号是不可变的，广告联盟可以通过网号更好地追踪你的上网行为。

IM 软件实名现在是必须的，你用网号实名和用身份证差不多。

我是装的 unraid ，跑了一堆 docker ，tailscale 来穿透，费老鼻子劲搞了公网节点弄好穿透，用起来其实没啥卵用，除了看内网的视频也没啥需要回家的业务，流量太贵了，回家的线路带宽也低，在家的时候下载好在外面的时候看体验更好一些。

这么搞的话，你想买的票的全程票都被黄牛买了，你只能付出溢价给黄牛，铁总显然不想这样子。
铁总以前的解法是用二等座的价格卖无座票，空出来的作为给买了无座票的人坐，还能多卖一点票变相提升运力（一定程度上缓解供不应求的问题）。

后面的解法是候补，一开始只放一部分全程票，让想买票的人都进候补队列，然后根据候补的情况供应不同路段的票，也会视供求情况调整座位（卧改座）加车厢甚至加车次（你候补的时候可以勾要不要候补新加列车），明显这个路子是更合适的。

我觉得后面考核铁路系统的指标就不是抢票这种没啥卵用的东西了，会变成有效需求的供给情况，让候补的人尽可能都能出行（最极端的情况是，只要你能忍受一路站下去，就一定能坐上车）。

没房子娃咋上学？

请先定义“强类型”

luban ，可以支持复杂类型、关联 ID 和分表，展示界面还是依赖 excel ，但可以支持 csv 或者 json ，能用文本的 diff 工具（ xlsx 文件也可以用 beyond compare 这类工具去看差异），资源类型的配置有一个内建的校验器可以配置校验，但是想要实现自动完成/提示/搜索需要自己针对配表工具去开发。

多人协作这块，没有银弹，比较好的做法还是分模块不同的模块不同的人去处理，避免多人编辑同样的文件，这块 luban 的支持也比较好。

---

以上是 luban 的优点，缺点也很突出，类型系统对策划同学来说过于复杂，配置语法杂乱，扩展性没有它自称得那么好，对配置本身的编辑体验没有帮助。

二次开发的话，可以在 luban 的类型系统的基础上，用 Excel-DNA 写一些扩展，加强编辑体验，不过肯定需要投入人力物力去做这个事才能有比较好的结果。

客餐厅无主灯，卧室没做是不想压层高。做了还是效果好一些。

---
现在想法也有变化，觉得灯具满足照明的需求就可以了。

统一就高效吗？你喜欢的工具别人使用起来就一定效率高吗？
---

API 工具这种，我推荐在使用 JetBrains 家的各位使用.http 文件，可以放在 git 仓库里同步给所有人，也很适合 AI 去生成。

明显是流程的问题，code review 应该小步快跑，每个 commit 的内容少一些，反馈快一些，这样就不会改了一大堆全部被推翻。review 过了之后才会接受这个 merge ，才能进入功能测试流程呀，这样就不会出现产品上线等你这个 review 的修复了。

娃需要奶的情况下，带出去自驾玩会不会折磨的成分大于玩啊？

双方是对角线，那先手一方把棋子移动到尽头卡死对方的象不就赢了？

1. 把每天 5000 人访问这个指标转换为可以通过压测量化的指标：请求接口分布、每秒请求数、响应延时、并发连接数、数据库的 TPS 、数据库的连接数，一般认为在预期载荷的情况下，内存/CPU 等核心硬件资源使用率在安全线（ 50%）是符合预期的；
2. 编写施压端方案，这方面的工具或者方法就很多了，不同的业务场景适用的东西也不一样；
3. 确保施压端和服务端的可观测性，服务端重点是影响服务的可用性和稳定性的指标，施压端终点是影响用户体验的指标，这样才能产出有说服力的报告；
4. 执行压测，分析性能瓶颈，解决问题，直到压测表现符合预期

根据你的描述，很明显是业务逻辑的问题，包括但不仅限于死锁、死循环、资源争用、上游 API 的问题。

Java 没有默认参数、关键字参数这些功能，对命名参数也没有啥需求啊。。

因为 0 warning 真的不是一个简单的目标，也不是写代码的人都自觉就能达到目标。
不同的 IDE/插件，不同的 lint 工具，不同人的设置都会带来不同的 warn ，首先就得拉平所有人的工具集（短期内会损失工作效率）。
每个人都有自己的代码口味，对不同的规则有不同的取向，你们团队能不能实现一个“最大公约数”。
需要在 CI/CD 流程里配置 lint 检查，而且得和 IDE 一样（有很多规则的细微差别需要设置和琢磨，同样的规则在不同的语法解析器上甚至会得到不同的结果，这个并不是一个简单活）。
针对遗留代码，需要配置只检查修改的部分（你的 VCS 是不是支持，lint 工具能不能支持）
有些小团队人员变动频繁，这一套能不能一以贯之，能不能落实给每个新成员。