Blogs

现代论坛的选择，以及Discuz论坛迁移到nodebb

Discuz停更后需要替代论坛选择，实验了好几种，简单的说下感受和迁移方法。以下按Github排名顺序 discourse 这个是排第一的论坛，但是是基于ror的，ror的性能差的不是一点点，内存占用也大，所以直接放弃。举个例子，我们之前的登录系统就是ror做的，爬虫在爬我们的discuz论坛时，由于每个帖子下都有一个登录链接，带了from参数都不一样，有些弱智爬虫都会爬一遍，该页面只是渲染登录框，就直接把ror的登录系统给干趴下了，而同样在被爬的discuz却无丝毫波动。习惯discuz的速度和经济性的做好准备，看你是否能忍受了。 flarum 这个界面非常不错。基于php+mysql，理应性能问题不大，但是论坛的sql查询没有做好，空论坛访问初始帖子会有100个sql查询，打开速度100ms起，如果用低配云数据库200ms都是正常的。这个速度加上其他的加载内容，快要1秒等待时间。 nodebb 这个是用nosql+nodejs做的，性能强，cpu很低。而且是基于websocket长链接的，响应速度非常快。内存占用起始1G，但增长慢。插件和api齐全所以选择了这个。 apache / answer 这个也很不错，类似知乎stackoverflow。但是我找了一圈没有把提问，采纳这种功能去掉的方法，如果能去掉的话，就是一个以文章(长篇主帖)为中心的论坛了，适合不需要太多交流功能，攻略向的论坛。 flaskbb / flaskbb python的论坛，性能很不错，但是很久没更新了。 rafalp / Misago 一眼二次元论坛，同样python的，作者刚开始开发没多几年，但倒是很勤奋。看了下他用了python的SocialAuth库，可以集成qq,weixin,google等各种登录方式包括集成自己的网站也是很容易的。另外国人有2个论坛看着也不错，一个Casbin高仿v2ex，还有bbs-go和symphony看着类似csdn的blog，但我都没实验。 Discuz 迁移 nodebb如果有自己的网站，nodebb迁移通行证可以用nodebb-plugin-session-sharing或者nodebb-plugin-sso-oauth2-multiple这2个官方插件。至于discuz导入，只能自己写代码了，让AI用python帮你写一个框架，剩下的自己改。如果只需要导入帖子的话，循环discuz的posts表，每行就是一个帖子，first=1就是主题贴。对于主题帖，调用nodebb的api/v3/topics/接口，对于回复，调用api/v3/topics/{tid}接口。用户的话可以用用户创建的接口，由于我用的session-sharing，用的是api/session-sharing/user接口，查询用户是api/session-sharing/lookup?id={passport_id} API的处理速度为5次每秒，做好慢慢迁移的准备。调用示例： async def create_topic(title, body, timestamp, category, tags, uid): # 创建主题 POST data = { "cid": category, # 板块号 "title": title, "content": body, "timestamp": int(timestamp), # 毫秒时间 "tags": tags, "_uid": uid # 发帖人 } # api管理员密钥 headers = {"Authorization": f"Bearer 1239383-3323-2323-2323-asd123123123"} # 调用 async with aiohttp.ClientSession() as session: async with session.post( 'https://xxx.com/api/v3/topics/', headers=headers, json=data ) as response: if response.status != 200: # 如果是“请增添发帖内容，不能少于 1 个”这种错误，就是content没escape response_text = await response.text() raise Exception(f"Error creating topic {title}: {response_text}") result = await response.json() topic_object = result['response'] return topic_object['tid'] 注意，API发帖和用户发帖是一个逻辑，受到论坛的所有字数限制，另外同样，timestamp也因为这个，导致设置了无效，会依然按最新时间发表，解决办法是修改 src/api/helpers.js 16行的时间戳，直接注释掉data.timestamp = Date.now();这行就行了。迁移完记得改回来，不然用户也能改时间了。

2025-02-17 14:14

Unity Job系统和Burst傻瓜教程，该怎么用才正确？

如果单就多线程目的，使用Async切换线程或System.Threading是最方便和清晰的方法，Burst也可以直接调用，并不一定需要Job，见异步篇和直接调用篇文章。但如果是大量小运算，此时你才需要考虑Job系统。 Unity Job文档极其不全，本文为长期使用经验记录，应该较为全面。 Job的目的和限制不同于一般多线程思路，Unity Job系统是一种通过多线程模拟GPU高吞吐量的系统，也就是说分配任务开销极小。 Job只能承载1帧内的运算量，和cuda/shader的函数一样是小内核。繁重运算依然会影响FPS，因为Job有时会分配给主线程运行。如果你希望运行长时间的计算，要么拆成很多小Job，不然.Net线程还是最好的。那么问题来了，既然是类似GPU，为啥不直接用ComputeShader？没错，Job的工作ComputeShader都能做，而且更方便。除非：如果需要频繁和CPU交换数据，GPU不擅长此事，基于CPU的Job就有优势了 ECS（DOTS）系统是基于Job的，原因同上注意，WebGL不支持Job和ComputeShader，也不支持Burst加速，但： WebGL在被WebGPU替代，WebGPU支持ComputeShader，且新版浏览器都已支持（IOS17需要设置中开启，19预览已默认开启）。设置里WebAssembly 2023可以开启多线程支持Job，且浏览器支持更全面。但官方说连实验性功能都算不上，不可使用，Unity6 LTS开启会Crash。wasm多线程让他们纠结很多年了，况且目前DOTS比较被重视，加上.Net8支持wasm多线程，也许他们在等Unity7支持.Net8。性能提供性能指标可以方便理解设计意图和适用性，你也可以先看文章再回头过来看性能测试。测试了8个项目，先是测试了3种分配器的性能： BenchAllocatorTemp: 执行100,000次Allocator.Temp分配 BenchAllocatorTempJob：同上，分配器Allocator.TempJob BenchAllocatorPersistent：同上，分配器Allocator.Persistent 结果是TempJob最快，其次Persistent。然后测试4种Job模式的性能： BenchBaseLine：用For执行100,000次简单计算作为参考基准线 BenchIJob：排程100,000次Job的时间 BenchIJobParallelFor：用并行模式批量排程100,000次Job的时间 BenchIJobParallelForBurst：同上，但打开Burst BenchIJobParallelForBurstLoopVectorization：排程10个Job，每个Job用For计算10,000次，并打开Burst向量化以下是我PC测试效果： Median就是测试项目耗时中位数，单位毫秒。可见Job排程开销小，是为了执行大量任务设计的。当然我这里只进行了简单的乘法计算，所以Job提升有限。数据类型首先Burst不支持C#托管类型，只能用和C一样长度的，可以直接memcpy（无需序列化编组）的类型，叫blittable，包含基本类型int等（char, string和bool则有时是托管的，别用），以及blittable类型的1维C-Style array(new int[5])。而Job必然和Burst组合使用，所以跟着此限制。 Unity为此封装了个NativeArray线程安全类型，专为Job使用。这些类型可和主线程共享数据无需Copy，因为复制时只会pass数据指针，多个副本都引用相同的内存区域。衍生的有NativeList,NativeQueue,NativeHashMap,NativeHashSet,NativeText等，但这些只能在单线程中使用。注意：不能用nativeArray[0].x = 1.0f，或nativeArray[0]++;这种代码，值不会变，因为他返回的不是引用。线程安全线程安全通过限制调度实现，同一个NativeArray实列只能执行1个Job对其写入，不然会抛出异常。如果数据可以通过分段实现并行，可以用IJobParallelFor对NativeArray分批执行。如果是只读数据，可以定义成员变量时用比如[ReadOnly] public NativeArray<int> input;来标识。 Job写入时，主线程不能对NativeArray读取，会报错，要等待完成。内存调配（allocate）首先，Native类型使用完需要你手动Dispose()，并不会自动销毁，为此Unity增加了内存泄漏跟踪。 Native类型new时需要选择Temp,TempJob,Persistent3种类型分配器，分配速度从快到慢，Temp 1帧生命周期，TempJob 4帧，这些什么意思呢？ Temp意思就是给你在当前函数内用，函数结束前就Dispose()，因此忘了Dispose后Unity下次渲染立即就会报错，但这个分配速度其实很慢 TempJob就是较为宽松的报错条件，实际还是让你在1帧内用，只是可以在下一帧Dispose Persistent不会报错，要你自己小心之前性能测试的BenchAllocator项目就是测试这3个的性能，可以看到Allocator.Temp耗时反而是TempJob 4倍，文档说Temp是最快的，这要么BUG，要么就是Editor模式问题。执行单线程Job整个流程就是自己写个IJob类，主线程Schedule它，然后调用Complete堵塞等待Job完成。 public struct MyJob : IJob { public NativeArray<float> result; public void Execute() { for (int j = 0; j < result.Length; j++) result[j] = result[j] * result[j]; } } void Update() { result = new NativeArray<float>(100000, Allocator.TempJob); MyJob jobData = new MyJob{ result = result }; handle = jobData.Schedule(); } private void LateUpdate() { handle.Complete(); result.Dispose(); } 但问题是，我们用Job就是为了大量任务，这种单个任务的作用不大。参考GPU的并行模式更有用。

2024-12-09 16:56

Unity Async异步教程，到底和.Net原生的有啥不同？

Async/Await是啥就不介绍了，类似协程但是更简洁，这里默认你有现代异步编程的知识。总结下Unity内部实现，方便搞清楚到底干了些什么。简单说就是，Unity内部做了一些处理，保证了2点，调用方是主线程时：1.调用方不会发生线程切换，2.被调用的异步函数不会执行在其他线程。 Unity对Async模式的目标 Async模式更现代化，是未来方向，但Unity目前并不打算用Async替代协程（IEnumerators），主要目的是用在IO类等操作上。 Unity Async性能比协程高，但并行数较低适合单件/主体类对象使用，比如摄像机，界面，IO方法等。少量Async性能高于协程，对于大量Object都需要并行运行的代码，仍然应该使用协程。性能部分尽量返回Unity包装的Awaitable，而不是Task （Unity6） .Net的Async是用Task来做，如下: async Task function() { await Task.Delay(1000); } .Net原生的Task每次返回都是新建对象，Unity包装的Awaitable对象是共用的，因此GC压力比较小。Awaitable还有线程切换“免费”（无损耗）的优势，见下一节。 async Awaitable function() { while(true) { await Awaitable.NextFrameAsync(); } } 对于需要反复await的方法，类似上述示例代码，请使用Awaitable返回值。当然IO那种一次性await的方法无所谓。

2024-12-05 19:55

Unity Burst加速直接调用代码示例

Burst文档和示例较少，除了Job方式调用外，也是可以直接调用的。以下是对球体的所有顶点生成uv的示例代码，用burst大概加速50%。 using System.Runtime.CompilerServices; using Unity.Burst; using Unity.Mathematics; [BurstCompile] public static class ParallelMethods { [MethodImpl(MethodImplOptions.NoInlining)] [BurstCompile] public static unsafe void GenUVs([NoAlias] in float3* vertices, [NoAlias] float2* uvs, int count) { for (var i = 0; i < count; i += 1) { // Unity.Burst.CompilerServices.Loop.ExpectVectorized(); 无效 var p = vertices[i]; var longitude = math.atan2(p.z, p.x); var latitude = math.asin(p.y); uvs[i].x = longitude / math.PI2 + 0.5f; uvs[i].y = latitude / math.PI + 0.5f; } } 直接调用方法如下：

2024-11-05 06:20

一种新型网游服务器引擎设计思路

有没有一种游戏服务器架构，即是分布式，但又像写单线程程序一样简单，数据会自动推送，隐藏无需关心的API只注重逻辑？缘起游戏服务器早期都用c语言开发，周期慢调试酸爽，后来开始改用luajit了，我们算激进的2009年就改了，毕竟网游比较看重性能，实际动态语言易于开发，和灵活的特性比性能更重要。在不断改进功能和重构中，意识到代码任务依然繁重，跟不上越来越快的迭代需求，很多功能无法立即实验并测试，想要改善得再换个语言，并从概念上重新设计游戏服务器。服务器即数据库以往的结构都是游戏服务器接受客户端指令，处理逻辑，然后去操纵数据库，最后返回更新数据给客户端。这个过程本身就带来了复杂度，所以不如直接隐藏数据库，或者说合为一体，游戏服务器就是数据库。有这样的想法其实很自然，一直以来网游就讨厌关系型数据库，要么直接用简单的内存mapping，有效又快捷，要么用Redis之类nosql。其次最好的数据库永远是定制数据库，因为不同的业务取舍各不相同。那就不如直接把服务器设计成一种专门为游戏客户端服务的数据库接口，当然后端还是由真正的数据库来负责持久化，但彻底隐藏掉数据库操作，内部自动处理。下面把游戏服务器称为db，后端真正的数据库称为backend。首先游戏客户端可直接对db订阅查询（select … where …），订阅内的任何数据变动db会自动推送，包括on_insert/on_update/on_delete等事件。表要设置简单的权限，让客户端只能查询自己相关的数据。但有些表应能设为guest权限，比如服务器在线人数状态，让未登录的客户端都可以查询。客户端只能订阅，没有写入权限，写入要通过db逻辑代码，就是传统游戏服务器逻辑，既然是db，也可以叫储存过程。客户端直接call名字，db执行对应函数。大多数情况不用返回执行结果，因为可以通过推送自动体现。 db逻辑代码中的读取/写入操作都要包装在一个事务中，然后自动提交给backend，如果事务冲突则自动重试。这样写的时候不用考虑竞态，部署也会更加灵活。此形式无论客户端还是服务器端，写起来都会非常舒服。客户端只要订阅数据，就能通过数据事件自动处理UI，或场景中的物体，和服务器逻辑大幅解耦。服务器端则可以只写真正的逻辑，不再需要关心和游戏客户端传送任何更新的数据。特性取舍这主要是平衡变种不可能三角：性能，灵活性，和数据一致性，提高某一项会拉低其他某项。首先是性能，可采用webserver类似的负载平衡分布式结构，因此性能只会受制于backend数据库，所以用性能较高的redis，而且redis自带mq，不需要再套一层。redis可以做横向扩展提升性能，但牵涉到数据一致性取舍。最后redis维护和展现数据不方便，一般是redis只做cache，之后再叠一层mysql来做持久化，但会增加不少复杂度，大幅降低灵活性，redis是可以胜任持久化的，也可以实现索引，不如只用redis，数据的维护和展现我打算之后交给数据科学相关的库来解决。灵活性包括故障和维护方面。这方面放弃高可用，遇到错误客户端直接断线并连接另一台服务器，游戏可以做成无感重连，也可以直接重登录。维护上最好做到一键开服，方便动态增减配，可大幅降低成本。故障自动恢复可以通过设置自动重启实现，这需要良好的数据一致性，让故障时无需数据回档/修复等操作。最后游戏对数据一致的要求很高，首先分布式的数据竞态怎么解决，以及程序crash/宕机时写一半的数据怎么解决，总不能扣了玩家钱东西没发放，这是必选项。最好的方法是通过backend事务来实现，但事务会大幅降低backend的性能，哪怕是redis，也会降低2个数量级。如果不通过事务实现，因为牵涉到索引，要通过锁或其他方式，这些都写起来非常麻烦，而且也会牺牲所有维护上的灵活性，因此这里选择事务，牺牲backend性能。然后是backend可以通过分割事务，来支持横向扩展，并保持一致性，后面会谈到。语言和更多性能考量其实lua和现代语言比起来，并不是那么便捷，甚至c++11的很多特性都比lua舒服。加上lua的库少缺乏维护，游戏服务器淘汰lua已然是必选项了。 rust是一个不错的选择，安全性，性能，现代化，全方面满足。但我倾向于选择动态语言，最好是一门书写很方便的动态语言比如python。其实只要支持分布式，瓶颈就完全卡死在redis上，语言的性能都无所谓，现在cpu比人便宜，如果服务器维护又方便的话，通过竞价服务器还可以再便宜50%。大家甚至对docker降低的30%性能都无所谓了，方便要紧。 python的库很多，比如表读写完全可以用numpy array来包装起来，处理和筛选数组会非常顺手，举个例子，交叉索引： array = money_table.query('last_update', left=now - 3600, right=now) poor = array[array.money < 999] poor.money += poor.money.mean() 在本地进行二次筛选，选出所有行中money低于999的，最后再向量化处理数据

2024-05-08 03:15

智能控制RGB灯带解决方案2.0 （13元+WIFI)

鉴于乐鑫产品越来越便宜，社区越来越丰富，这里推荐更好且更便宜的方案。需要的材料为：灯带：建议为5V RBGW 3P灯带。3P是信号控制，花样多，5V是因为控制板也是5V输入。坏处是只能1米以内长度。灯带电源：根据你的灯带选择，瓦数要符合控制板：合宙ESP32-C3，9.9元包邮，安装wled，插入usb直接浏览器就能装：https://wled-install.github.io/ 适配器：TXS0108E 8路电平转换模块2.5元包邮，把控制板的芯片3.3V信号转为5V 5V正负极接控制板5V和GND Pin，适配器的5V和GND，以及灯带的正负极控制板3.3V Pin接适配器 3.3V口信号线从控制板GPIO0接电平转换的D口，对应5V D口接灯带信号口完成后手机连接控制板的wifi，密码wled1234，简单配置下：设置灯带的型号（大概率SK6812），可控制接口(接GPIO0就填0)，即可。接下来手机控制，或者homekit语音都可控制。效果方面，走马灯也好，甚至多条一起播报文字都行我并没有这样实际组装过完整的灯带，但这么自制过RGB打光器，可以作为参考。实际灯带可能需要mosfet来配合控制，具体wled网站上有各种方案。

2023-02-01 03:08

3D打印机 Ender 3 V2 高速改造升级经验

作为高性价比DIY机，Ender 3 V2速度是真的慢，一开始觉得没必要升级，其实打印头改造只要60元，早改早享受，速度翻倍就相当于有了2台。而且整个改造除了主板调压，不需要动主板其余任何部分，和双Z一起改就行了。 Ender 3已经是网上资料最多的打印机了，过程中还是遇到了很多没有资料的情况，下面是我的升级路线，可以按顺序改造。 1. 挤出首选遇到的是挤出打滑，导致打一半刨料，打印失败。这个是单齿轮挤出机的问题，一般换23元的国产BMG克隆挤出机可以完美解决。这是最容易升级的，又不贵，而且大部分近程打印头都会用到这个BMG挤出机，横竖不亏。装完后E轴传动比要调为425.5，屏幕里面可以设置。 2. 填充溢出/大象脚/挤出过剩然后是底层或顶层完整填充的时候，会有溢出的情况，一开始以为挤出过剩，打印花瓶方块做挤出调校时，发现右边那一面的线条宽度总是比其他的小。这是因为Ender 3是单丝杆机器，只有左边有丝杆支撑，右边是悬垂的，所以在提升z轴时，右边到底提升多少高度看它心情，而且前几层必定提升过少，0.2的层高可能一开始每层只提升了0.1。松右边滚轮的螺丝可以缓解一丢丢。层高不准确严重影响质量，也影响遇到很多问题时的调试。如果想看到完美的层纹，必须进行升级。 1688花77元买了双z轴套装，说不需要拆主板，整个安装很方便。装完试打结果每次打印都需要调平，而且怎么调都调不平，打印过程中也有波浪纹。双z修复1：修改电压一是因为z轴2个步进电机并联了，导致步进电机电流不够。本来发烫的步进电机摸起来都是冷的，所以扭矩不够让丝杆打滑，层高还是不稳定。解决方法就是增加步进电机电流，但我发现无法通过软件改，无论是在固件里面还是M906命令。原因后面会说。只能拆主板，用万用表调整主板上Z轴步进电机驱动的$V_{ref}$电压，每个步进电机驱动旁有个调整的旋钮，用万用表边测量电压边调整（当心碰到其他地方短路）。首先是公式，TMC系列的公式是：$\frac {I_{max}} {\sqrt 2}=\frac {325mV} {R_{SENSE}+30m\Omega} * \frac 1 {\sqrt 2} * \frac {V_{ref}} {2.5V}$ 我的主板上贴片电阻是R150，所以小学数学： $R_{SENSE}=150m\Omega$ $\frac {I_{max}} {\sqrt 2} = \frac {325mV} {180m\Omega} * \frac 1 {\sqrt 2} * \frac {V_{ref}} {2.5V}$ $\frac {I_{max}} {\sqrt 2} / (\frac {325mV} {180m\Omega} * \frac 1 {\sqrt 2} * \frac 1 {2.5V} ) = V_{ref}$ $I_{max} * \frac {2.5V} {\frac {325mV} {180m\Omega}} = V_{ref}$ $V_{ref} \approx 1.3846153846153846 *I_{max}$

2022-09-05 02:52

智能控制RGB灯带解决方案

为了给电脑桌台上下配RGB灯带，看了下tb jd上相关的产品，怎么说呢，可选不多，要么贵的要死，要么设计很烂，也无法手机控制。鉴于家里已经有Aqara网关，就找了绿米的相关产品。顺带一提，如果你会玩IoT开发板，用ESP32+MOSFET开关+WLED开源系统是最好的解决方案，成本15块钱。绿米是这个：Aqara智能灯带驱动模块，100元：灯带你需要买RGBW，有5个pin，分别为电源+, r,g,b,w暖白光控制信号，我买的24V的10米，120元。然后要24V开关电源，我试了淘宝上好几个LED开关电源，都有高频噪音，最后只能选贵贵的西顿的开关电源。估计用明纬的也可以，就是不知道尺寸行不行，LED开关电源都是扁的。我为了连接上下2个灯带还用网线接上5pin头，做了延长线：安装简单，按标识接入即可。最后效果： App控制界面：动态效果就是简单的渐变，我本来以为和电脑一样有走马灯效果的，结果自然是没有。而且还有个严重问题，就是动态效果的状态不会保存，关灯后再开就没了。找不到地方反馈和询问这个问题，好在可以在自动化里设置灯光效果，每次打开时用自动化设置一下动态就行能解决了。这玩意支持Homekit，但在Homekit里无法设置动态效果。不过能通过Homekit Controller接入HomeAssistant，然后你想怎么编程都行。 10米的RGB，还带手机控制，可接入小米，HA，总价220元搞定，便宜多了。不过RGB灯比想象的要耗电，大概40瓦，用下来一个月25度电，只能开50%亮度了。

2022-04-17 02:52

管道新风的设计和安装的经验，附带结果实测

之前家里装修安装了管道新风，疫情闲着没事做，测量下家里新风风速写个总结和设计要注意的事项。简单地说，一定要自己进行风速和风量的计算，然后提出要求，不然装出来肯定不达标。管道新风的问题最首要的问题就是噪音和换气能力的取舍，机器本身马达噪音和风口风声非常响，随便装装很大概率就因为噪音不愿意开了，不是7x24小时开还叫新风？风口噪音和风速直接相关，风速和换气能力相关，这需要权衡得失，厂家设计师并不会考虑这个。计算方法这里我列出我们基本目标：每小时换气次数：0.8次(国标)，最好翻倍，1.6次以上，这样你可以日常开半档符合国标还低噪音风口风速上限：3.5m/s(国标)，目标2.5m/s 这是管道常量：注：现在新风都是PE管道，不要再考虑PVC管道了。 PE口径mm: 75 PE内径mm: 63 PE截面m2: 0.003117 PE单位通量m3/h: 11.22208 然后对每个房间计算如下数据：面积m2：输入层高m：输入体积m3：=面积 * 层高目标换气量m3/h: =体积 * 每小时换气次数需要出风口： = 目标换气量/PE单位通量/风口风速上限以上就能算出每个房间需要的出风口数了，回风口数可以简单地比出风口数少一个，但至少有一个。我设定的目标参数：卧室客厅换气数次/h 2 1.8 限噪风速 m/s 2 3.5 PE口径 mm 75 75 PE内径 mm 63 63 PE截面 m2 0.00312 0.00312 PE单位通量 m3/h 11.2221 11.2221 面积 m2 10 35 层高 m 2.7 2.7 体积 m3 27 94.5 需换气量 m3/h 54 170.1 需出风口个 2.41 4.33 新风机都有换气量这个基本性能指标，把所有房间的目标换气量求和就是需要的新风机性能，上表就需要一个风量至少54+170=224的新风机，也就是要250机型。

2022-03-28 23:25

全屋净水20寸大白瓶对水流量影响的实测

选择哪个？对出水大小影响多大？我简单的测试了一下。放弃前置过滤器之前为了去除水中的颗粒，装了前置过滤用了2年多，结果完全没有用：反冲洗没多少东西，观察滤网也干干净净，我这还是老公房带水箱的，可能是上海地区限定。前置那40um精度唯一意义就是过滤泥沙，选择直接装滤棉，外加为了装软水机，要除余氯后才能长寿命工作，还要加个活性炭滤芯。大蓝瓶？大白瓶？考察了大蓝瓶和大白瓶，其中大蓝瓶是非零售工业用，防爆比白瓶弱，因此需要一堆附件，而大白瓶直接一个解决，价格和蓝瓶联装比起来也没差多少，这时候根本不需要考虑，less is more 最后在线下的授权店那直接订了 BFW-20寸大白瓶+RFC20BB复合滤芯，10um精度，价格1600带安装，带官方微信可查的防伪标识。如果自己线上买自己装可能1300可以搞定，但是没防伪标识。线上貌似有假货，线下的又贵，不知道怎么判断真伪，厂商好像也不关心线上的样子，坐等以后国产化替代他。水流量的影响实测很多人怕影响水流纠结到底选几寸的，要不要联装，网上说法也各种不同，这里我提供我自己的实测数据。水压不需要测试，因为不管你装多少设备，静态水压是基本不变的，所以水流量才是正确的测试方式。测试环境：滨特尔20寸大白瓶+RFC20BB复合滤芯；家中水管为6分DN25x4.2 S2.5，入户水管为1寸管；家中4个龙头全开：4分软管冷水龙头x2(内径9mm)，淋浴龙头x2(内径16.4mm) 20"大白瓶过滤直通Bypass 统计值统计时间/秒 17 17 家中龙头全开，起始水表/m3 0.6286 0.6559 看2种情况下水表计数结束水表/m3 0.6354 0.6635 总流量/m3 0.0068 0.0076 总流量/L 6.8 7.6 单位流量流量m3/s 0.000400 0.000447 流量m3/h 1.440000 1.609412 流量L/s 0.400 0.447 流量L/分钟 24.000 26.824 管道常量 ppr6分内径 16.4 16.4 内径/m 0.0164 0.0164 截面积/m2 0.000211241 0.0002112 计算流速流速m/s 1.894 2.116 我家里水流速有点慢，不过可以看到，20寸大白瓶加复合滤芯对水流量的影响为10%。

2022-01-23 20:05

下一页 2/2