-
做国标视频平台，我为什么放弃了SRS选了它
先说结论 做国标视频平台，流媒体服务器我最终选了ZLMediaKit，放弃了SRS。不是因为SRS不好。SRS在互联网直播领域非常优秀，RTMP推流、HTTP-FLV/HLS拉流做得扎实，社区活跃，文档完善。但国标场景不一样。为什么一开始选SRS？ 去年开始做国标平台的时候，我第一反应是用SRS。理由很简单：SRS名气大，用户多，出了问题好搜答案。而且SRS 5.0开始支持GB28181，通过st
-
公司禁用开源工具，我用半年证明了什么
去年入职一家做车联网平台的公司，第一天开技术会，CTO 明确说了一句：“公司项目禁止使用来源不明的开源工具，出了问题谁负责？”我理解他的顾虑。商业工具有人兜底，自研工具可控，开源工具确实存在维护风险、安全风险、合规风险。但问题是，我们当时做 JT/T 808 联调，商业工具报价六位数，自研来不及，团队只能靠手写脚本硬扛。我偷偷下载了 JT-Simulate。为什么敢用？因为它开源，代码就在那里。我
-
为什么你的MQTT Broker一上量就崩？
评论区有位兄弟说他在工业园区用MQTT，每个网关连100个设备左右，跑了一年半了。这是个好案例。但我也见过很多MQTT项目一上量就崩——几千个设备同时在线，Broker就扛不住了。为什么有的项目100个网关稳稳当当，有的项目几千个设备就崩了？第一个坑：Broker选型不对。MQTT Broker有好几种——Mosquitto、EMQX、HiveMQ、VerneMQ、NanoMQ。Mosquitto
-
当 SPIFFE 走进工厂：我把云原生的零信任身份框架装进了 Modbus 传感器
SPIFFE 是 CNCF 的毕业项目，Kubernetes 生态里管身份认证的事实标准。但它最初设计时面对的是云原生工作负载——K8s Pod、VM、Serverless 函数-23。没人想过用它来管一个 Modbus 传感器的身份。但我做了。问题：一个工厂 5000 台设备，每台都是一个潜在的后门 传统 IoT 设备靠 IP/MAC 地址识别身份。这意味着什么？任何知道设备 IP 的人，插上网
-
我测了5个边缘AI平台，最后选了最“寒酸”的那个
上个月帮一个做设备运维的朋友选边缘 AI 平台。他的需求很朴素：工厂里有 200 台设备，装了振动和温度传感器，想做个异常告警，预算不高，不想换硬件，不想数据上云。我陪他测了 5 个平台，结果挺意外的。测试对象和结果平台部署耗时最低内存断网可用多模型编排本地 LLM硬件绑定AWS Greengrass2 天1GB+部分❌❌倾向 AWSAzure IoT Edge1.5 天1GB+❌❌❌倾向 Azu
-
我花 3 天写的 808 解析器，被一条真实报文打崩了
前年接了一个道路运输平台的项目，需要解析 JT/T 808-2019 的位置上报报文。我当时的想法很简单：协议文档又不复杂，自己写一个解析器，可控、可定制、不依赖第三方。于是我花了 3 天，写了转义处理、校验码计算、BCD 解码、大小端转换，还写了一套单元测试。本地跑了几十条构造报文，全部通过。我当时觉得自己挺牛。然后真实终端接进来了。第一条报文就把我的解析器干崩了。终端手机号解析出来是乱码。我查
-
大规模设备接入，Netty还是MQTT？我把真实数据摆出来
上篇文章《用Netty还是MQTT》发出去之后，评论区吵起来了。有个兄弟说“瞎扯淡”。然后“林间隐居宁静致远”本人来了，说那段评论确实是他写的——他用Netty做了7年校园洗衣机项目，几十万台设备，稳定运行；后来做工业园区用MQTT，每个网关连100个设备，也跑了一年半。两段真实的项目经历，两种完全不同的技术选型。到底谁对？我说点更具体的。先还原一下两个项目的真实场景。项目A：校园智慧洗衣机（Ne
-
技术解读：【鸿蒙优选三方库】@ohos/aki：一行代码让 ArkTS 调 C++
裸写 NAPI 绑定一个 add(a, b) ，要写三十行 napi_get_value_int32 、 napi_create_int32 。绑定一个 C++ 类？更是一场噩梦。 @ohos/aki 把它压缩成一行—— 同样的功能，代码量减少一半以上 。
-
技术解读：鸿蒙平台 Subversion 客户端适配实战：基于 HTTP_WebDAV 协议的轻量级 SVN 图形界面_鸿蒙系统
Subversion（SVN）是经典的集中式版本控制系统，广泛应用于企业级项目管理。本文记录在鸿蒙 PC 平台上，基于 Electron 壳方案从零构建一个轻量级 SVN 图形客户端的完整过程——不依赖原生 svn 命令行，而是通过纯 JavaScript 实现 HTTP/WebDAV 协议与 SVN 服务器通信，完成仓库浏览、文件查看、日志检索、版本对比等核心功能，并详细记录鸿蒙平台特有的稳定性踩坑经验。
-
技术解读：Godot 游戏编辑器移植鸿蒙 PC：难度与可行性分析
分析对象：将 Godot Engine（游戏运行时 / 编辑器本体）移植到 HarmonyOS PC（鸿蒙 PC，2in1 设备）结论性质：基于公开资料的技术可行性研判，非实测报告。
-
技术解读：鸿蒙平台 KDevelop 集成开发环境适配实战：基于 Electron 壳方案的跨平台多语言代码编辑器开发-CSDN博
KDevelop 是 KDE 社区出品的开源集成开发环境，支持 C/C++、Python、JavaScript、HTML/CSS、PHP、Java 等 30 余种编程语言，提供多标签编辑器、文件树管理、全局搜索、符号大纲、查找导航等功能。本文记录将其基于 Electron 壳方案适配到鸿蒙 PC 平台的完整流程。
-
OpenHarmony跨平台框架生态：9大仓库全面解析
开源鸿蒙跨平台生态迎来重大突破！从 Kotlin 到 Flutter，从 React Native 到 Electron，开发者可以零成本将 Android/iOS/Web 迁移到全场景设备。本文将逐一说明各技术栈的核心能力与应用场景，助你快速选型、高效落地。 随着开源 OpenHarmony 生态的快速成熟，跨平台开发已成为多终端部署的主流方案。开源鸿蒙跨平台框架 SIG 组已完成 KMP、Cordova、React Native、Flutter、Ionic、Chromium、Electron、Qt 等主流技术栈的深度适配，使 Android/iOS/Web/桌面应用能够迁移到鸿蒙全场景设备。
-
技术解读：鸿蒙平台 Pylint 代码分析工具适配实战：基于 Electron 壳方案的 Python 静态分析开发-CSDN博客
Pylint 是 Python 生态中最主流的静态代码分析工具之一，能够检查编码规范、命名约定、潜在错误和代码复杂度。本文记录将 Pylint 核心分析能力基于 Electron 壳方案适配到鸿蒙 PC 平台的完整流程，实现一个支持 14 条规则检查、10 分制评分、Python 语法高亮、多文件标签管理的纯前端代码分析工具。
-
技术解读：插上就能用 vs 折腾半天：鸿蒙平板外接键鼠远控，ToDesk/向日葵/RayLink真实对比_平板用远程操控电脑鼠标-
前言：平板接上键鼠，远控才真正能干活 鸿蒙平板配蓝牙键盘和鼠标远控电脑，听起来很自然，但实际用起来差异不小。三款远控软件——ToDesk、向日葵和 RayLink——在鸿蒙端对外接键鼠的适配深度、快捷键丰富程度、指针模式灵活度，以及被控端锁屏时能不能顺畅解锁，直接决定了平板远控到底是"凑合用"还是"真的能干活"。 这次拿了一台鸿蒙平板、一把蓝牙键盘和一只蓝牙鼠标，把三款软件挨个接上实测，逐项对比它们在外接键鼠适配、快捷键便携性、指针模式和锁屏解锁四个维度上的表现。 一、外接键鼠适配：插上就能用，还是得折腾半天 远控场景下，外接键鼠不是锦上添花，而是刚需。用平板远控电脑处理 Excel、写文档、操作专业软件，光靠触屏根本不够。三款软件对蓝牙键鼠的适配程度，直接影响"平板替代笔记本远控"这个场景能不能成立。...
-
使用C#.net10 winform+antdui全新重构版本lol小助手
:::info 💡经过这段时间的沉淀，段位也是从黑铁打到白银了，lol小助手也在玩的时候不断优化更新了很多东西，这不，来跟大家分享一下成果。:::第一个就是现在可以舍弃掉wegame登录，直接从小助手上进行登录，目前已经测试没有问题了，路径在我们的设置-》客户端下面 第二个是首页跟对局的界面跟战绩优化了，评分、装备、kda、天赋、符文这些都有，适合时候复盘，并且有开黑检测，适合看队友或者对手是否有
-
点餐小程序源码-点餐小程序源码
桌码设计、订单状态机与加菜逻辑全链路解析一、桌码设计的核心逻辑扫码点餐系统中，桌码不仅仅是一个二维码，它本质上承载了门店ID、桌台ID和点餐入口三重要素。后台需要建立独立的桌台管理数据表，包含桌台名称、桌码参数、桌台状态、容纳人数等字段：sqlCREATE TABLE store_table ( id BIGINT PRI
-
最新点餐系统源码(ThinkPHP+FastAdmin+UniApp)搭建
一套代码编译小程序+APP+H5的工程实践一、Uniapp多端编译的技术原理Uniapp的多端编译能力基于条件编译和平台差异化适配。开发者通过#ifdef MP-WEIXIN、#ifdef H5、#ifdef APP-PLUS等条件编译指令，将平台特有的代码逻辑隔离，编译时自动裁剪非目标平台的代码，生成各端的发布包。Uniapp是一个使用Vue.js开发所有前端应用的框架，开发者编写一套代码，可发
-
车联网平台用微服务，是我见过最大的技术笑话
这句话会得罪很多人。但我还是要说。一个真实项目去年，一个客户找我做技术咨询。他们的车联网平台上了微服务，拆了30多个服务。我问他：为什么拆这么多？他说：微服务架构啊，高内聚低耦合，独立部署，技术异构。我说：你们多少终端？他说：5000台。5000台终端，30个微服务。平均每个服务承载166台终端。微服务在车联网的典型问题第一，网络开销。微服务之间通过HTTP或gRPC通信。一次位置上报，网关服务要
-
MQTT在工业现场用了3年，我总结的4个“不适合”场景
MQTT这几年被捧得很高。很多方案里，不管什么场景，先上一个MQTT Broker再说。但我用了3年MQTT之后发现——MQTT在工业现场有4个场景是真的不适合，硬用只会给自己找麻烦。场景一：安全联锁回路。一个化工项目，安全联锁系统需要在检测到压力超标后50ms内切断进料阀。有人提议“用MQTT下发切断指令，快得很”。这是要命的错误。MQTT的消息从发布者到Broker再到订阅者，中间经过了至少两
-
“开源工具能用在生产项目里吗？”我用 JT-Simulate 做了半年部标联调后的真实感受
每次在团队里推荐开源工具，总会有人问：“开源的东西，出了问题谁负责？”“代码质量能保证吗？”“会不会有安全风险？”我做部标协议开发六年，用过自研工具、商业工具、开源工具。说实话，没有哪个工具是完美的。商业工具支持好，但贵，而且定制困难。自研工具可控，但维护成本高，人员一流动就没人管了。开源工具免费，但需要自己判断质量。JT-Simulate 是我半年前开始用的。当时项目要做 JT/T 808 和
