Note

我们使用 Markdown 作为我们内容的格式，所以学习 Markdown 就显得很必要了。 Markdown 是一种轻量级标记语言，后缀为.md。因我常用 Markdown 来写一些内容，记录下来常用语法格式。方便自己查找使用，也增加自己的一些流量。Markdown 可以用来撰写电子书，文章，博客等。介绍标题、段落的使用。 标题 # 一级标题 ## 二级标题 ### 三级标题 #### 四级标题 ##### 五级标题 ###### 六级标题 段落 Markd 段落没有特殊的格式，直接编写文件就好，段落的换行使用两个以上空格加上回车。也可以使用一个空行来表示重新开始一个段落。 字体 使用如下格式分别表示斜体，粗体，粗斜体。 *斜体文本* _斜体文本_ **粗体文本** __粗体文本__ ***粗斜体文本*** ___粗斜体文本___ 分割线 你可以在一行中用三个以上的星号、减号、底线来建立一个分割线，行内不能有其它东西。你也可以在星号或减号中间插入空格。 *** * * * ***** - - - --------- 删除线 如果段落上的文字要添加删除线，只需要在文字的两端加上两个波浪线~~即可。 ~~删除线~~ 下划线 下划线可以通过 HTML 的标签来实现： <u>下划线文本</u> 脚注 脚注是对文本的补充说明。 [^要注明的文本] 列表 支持有序列表和无序列表。 无序列表使用星号、加号、减号作为列表标记，这些标记后面要添加一个空格，然后再填写内容。 * 第一项 * 第二项 * 第三项 + 第一项 + 第二项 + 第三项 - 第一项 - 第二项 - 第三项 有序列表使用数字并加上.号来表示。 ...

一、 那件披在身上的大衣 老家人养猪，冬天的半夜，都要披上厚重的大衣，去猪舍看产床温度。猪舍的墙上挂了一个水银温度计。温度低了猪仔会冻死，温度高了会脱水。氨气重了会生病，感觉味道重了，需要手动打开抽风机。这种“靠人巡、靠鼻闻、靠经验”的原始模式，不仅累，而且风险极高。 供暖烧煤炉，煤炉需要半夜起来加煤，人困得不行；母猪还得使用电热板，电热板是那种电阻丝加热的，没有温控计，只能隔几个小时去关掉，等温度降下去再打开。说到底，还是得靠人去“看着”。 我想，能不能用技术，把家人从这种重复、枯燥且充满风险的体力劳动中解放出来一点点？不用花太多钱，因为他们会心疼。 二、 攻坚方案：黑盒的温控逻辑 可以看到面临的主要是“环境失控风险”。 温度控制的极端性：依靠烧煤和简易电热板，温度分布不均。半夜人工起夜不仅辛苦，且这种“大跨度”的温差变化会导致猪仔腹泻甚至死亡。 空气质量的隐形威胁：氨气超标是诱发呼吸道疾病的主因。仅靠“鼻闻”时，空气质量往往已经恶化到危及健康的程度。 利润被风险蚕食：养猪大头是料钱和药钱，但成活率才是利润的底线。一次深夜的失误，可能让数月的辛苦付诸东流。 能马上想到的临时解决方案： 恒温自动化（解决“半夜加煤”与“手动插拔”） 温控传感器方案：购买带有探头的温控开关，将电热板连接到温控插座上。 效果：设定好区间（如32-35度），温度低了自动通电，够了自动断电。不仅省去了人工看管，还能通过减少无效耗电抵消设备成本。 环境预警系统（解决“鼻闻”与“风险”） 智能监控终端：安装一个集成了温湿度监控与氨气检测的智能传感器，通过 Wi-Fi 或 4G 信号连接手机。 效果：当温度异常或氨气浓度过高时，手机会自动发出警报铃声提醒，避免了老人家整晚不敢闭眼的焦虑。 联动抽风（解决“呼吸道疾病”） 自动排风系统：将原有的抽风机改装为智能联动。 效果：当氨气传感器感应到超标，自动开启抽风机，达标后关闭。这能精准减少热量流失，同时保证猪舍空气清新。 核心硬件选择：务实与成本的平衡 因为猪舍现场环境非常恶劣，湿度，氨气，粉尘等因素，温控开关坏的频率非常高，如果接到料房，又采集不了温度。购买氨气专业设备成本又非常高。现场可以根据温度和通风进行解决，但在冬季，保暖是另一个问题。实际考量后，还是自己动手做比较划算。零部件能够直接买并满足现场需求的，直接购买，满足不了，自己动手制作，需要防腐蚀处理：焊接完成后，用酒精清洗焊渣，然后必须喷涂“三防漆”。外壳选用 IP65 防水接线盒，进线口使用电缆防水密封接头 (PG7)，否则氨气会从缝隙钻进去。线路外层加PVC管，防鼠咬，腐蚀，机械损伤。 传感器：水银温度计不行，无法采集。工业级的 RS485 温湿度传感器太贵（动辄上百元），购买不锈钢封装好的民用级的DS18B20数字温度传感器，焊接后要密封好，挂在猪舍合适的位置。它通过一根单总线连接，协议简单，成本极低。 主控：具备 NB-IoT 通信功能的物联网核心板或者采用分布式架构，先接一个STM32控制黑盒，然后再连接物联网黑盒，它集成了主控芯片和 NB-IoT 模块，可以直接连接运营商网络。它负责读取传感器、执行逻辑、控制输出，并具备联网能力。 通信：猪舍没有Wi-Fi，即使有WiFi，也推荐使用RS485线连接，考虑如下：稳定性以及长期收益。布线不方便的地方，可以使用4G或者NBIot模块，用一张物联网卡，可以直接走运营商的网络上传数据，无需在猪舍和住房之间拉网线，年流量费仅需十几元。这是实现“无线化”的关键，需要注意的是，如果在猪舍内加装铁盒，需要接外接天线，防止信号屏蔽。 报警：前期控制投入，不用手机流量卡和云平台。购买一个433MHz无线门铃，使用黑盒驱动，黑盒使用IP65 防水塑料接线盒，把发射模块接在主控板上。当需要报警时，主控板模拟按下门铃按钮，屋里就会“叮咚”响。这是最直接、最可靠的本地告警。 第一阶段：从“定时巡”到“听铃响” 目标：解决“夜间需要频繁固定间隔的去猪舍”的核心痛点，将人工巡检间隔时间拉长到“只在有异常时响应”。 系统架构与原理： 感知：主控板 不断读取 DS18B20 的温度值。 决策：我在主控板的固件里写死一段简单的判断逻辑（例如：if (温度 < 18度 或 温度 > 28度)）。 执行：一旦条件满足，主控板 立即驱动 GPIO 引脚，向 433MHz 发射模块发送一个高电平脉冲信号。 告警：433MHz 信号被屋里的门铃接收器捕获，触发响铃。屋里的人听到铃声，就知道猪舍温度异常，需要去查看。 可执行性与落地关键： 硬件连接：仅需将 DS18B20 的数据脚、电源、地线接到主控板对应引脚；将 433MHz 发射模块的信号脚接到另一个 GPIO 引脚。接线简单，无需复杂电路。 ...

一、 场景：从“插卡洗澡”到“手机充值”的断层 “洗澡洗一半，卡里没钱了，得湿着身子跑下楼去圈存机充钱。”——这是十年前大学宿舍的常态。 我参与过那个“刷卡时代”的项目。彼时，每个宿舍楼都有一个弱电井，里面几十个水表通过RS-485总线串联。学生用M1卡洗澡，钱存在卡里，水表是“单机版”。宿管中心不知道哪个宿舍快没水了，只能被动等待报修。 核心痛点：用户需要手机充值的便捷，但海量的老式水表（及电表、热表）是“数字孤岛”，只有RS-485接口，不具备任何联网能力。整体更换为物联网表成本极高，且施工影响巨大。 二、 方案：一个“黑盒”，唤醒沉默的数据 我们的方案是添加一个 “黑盒”——一个协议转换网关。它的逻辑很简单：不换表，不改线，只做“翻译官”。 物理部署：在弱电井的485总线汇接处，并联接入“黑盒”。原有的刷卡系统完全保留，作为保底。 核心工作： 采集：黑盒内置高性能Modbus协议栈，主动轮询总线上所有水表，读取余额、用量。 转换：将不同品牌、不同协议的水表数据，统一“翻译”成标准的JSON格式。 上传：通过4G或网线，将数据通过MQTT协议上传至云平台。 手机充值闭环： 学生在小程序支付。 云端将“为XX房号充值XX元”的指令下发给对应黑盒。 关键一步：黑盒将指令“反向翻译”成目标水表能识别的、符合其私有协议的485报文，完成“写卡”操作。 系统确认后，充值到账。 三、 定位：在巨头缝隙中，做“数字化的梯子” 我深知，国家级、城市级的智慧水务/能源项目，是头部玩家的“铁桶阵”，他们依靠专用网络、5G和强大的工程能力构建壁垒。 “黑盒”的目标，是那片被忽略的“长尾市场”： 还未改造的高校宿舍、企业公寓、公租房保留的水表。 城中村的个体房东，管理几栋到十几栋楼房。 中小工厂的宿舍楼。 对他们而言，动辄数十万的整体改造方案是不可承受之重。而一个单价数百元、即插即用、半天可部署、不动原有设施的“黑盒”，是他们迈入数字化管理的唯一可行阶梯。 四、 挑战与壁垒：并非“即插即用”的童话 这个方案在逻辑上自洽，但真实的商业落地远非易事，存在多重壁垒： 工程实施壁垒：“不换表”不等于“零施工”。将黑盒接入弱电井，需要开井、找线、破接、取电、固定，这本身就有一定的技术门槛和安全风险，并非普通用户能独立完成。 协议适配壁垒：水、电、热表协议各异，且大量是厂家私有加密协议。适配、测试每个新协议，都意味着高昂的研发和现场调试成本。这绝非一个“通用字典”就能轻松解决。 性能与稳定性壁垒：RS-485总线是半双工，挂载几十块表后，轮询周期会拉长，数据实时性下降。网络波动、设备干扰可能导致指令执行失败，需要设计复杂的重试、容错和事务一致性机制。 渠道与商务壁垒：如何触达并说服高校后勤、房东这些分散的客户？如何提供及时可靠的现场支持？这比技术开发更难。 五、 结语：技术应俯身解决真问题 从弱电井里满是灰尘的RS-485总线，到云端的MQTT消息；从易丢失的实体卡，到手机里的数字账户。 “黑盒”的价值，不在于它用了多炫的技术，而在于它用极低的成本，为一个真实、广泛但被忽视的需求，提供了一个可行的解决方案。 它像一根“数字化的梯子”，让那些无力承担“电梯”费用的用户，也能攀上智能管理的台阶。 这背后，是对现场通信“脾气”（干扰、雷击、协议冲突）的深刻理解，更是对用户“简单、可靠、别添乱”这一终极诉求的敬畏。 当巨头们仰望星空，构建未来时，总需要一些人，愿意为角落里那些“老旧笨重”的设备，插上一双通往现代的翅膀。 这条路充满挑战，但正因如此，每一步才都踏在真实的需求之上。 后记与邀请 如果你正在寻找低成本的老旧设备数字化方案，欢迎交流。关于“黑盒”项目的固件核心进展、协议文档与配置字典，我将在爱发电https://afdian.com/a/modujson​ 持续同步与更新。

“以前看粮仓，那是体力活，现在看粮仓，是技术活。”——一位在粮库工作三十年的老保管员 一、那些年，我在粮库“插钎子” “我年轻时，最怕夏天查粮仓。”老保管员回忆道。三伏天，他得扛着十几斤重、6米长的铁杆，踩着晃晃悠悠的木板，深一脚浅一脚地爬上几米高的粮堆。杆子前端是温度传感器，杆子末端则是一个巴掌大的小型LED显示屏。每到一个检测点，他就得用力把这“铁签子”插进压得结实的粮堆底部，然后低头查看杆子末端的屏幕读数，再抄录到本子上。全部查完、记录完，要爬一整天。粉尘呛人、闷热缺氧，是家常便饭。 “那时靠的是腿，是眼，是经验。”老保管员说得对。他练就了“一看、二闻、三摸”的本事，但这套经验在几千吨的粮堆面前，总有盲区。一旦某个角落的粮食开始发热霉变，等人工发现时，往往损失已不可避免。 这不是故事，这是我的朋友——一位粮库测温系统的实施工程师——告诉我的： 他入行时，老保管员的手艺活已是过去式。他面对的是更“现代”的麻烦：部署一套有线测温系统。 这套系统的核心，是把带有固定传感器的“测温电缆”像神经一样埋入粮堆，取代人工巡检。而他的工作，就是把这套“神经”铺进去，再把“信号”引出来。 这活儿，一点不比爬粮堆轻松。 夏天，粮仓内像个蒸笼，地面温度超过40度。他要在入粮前，或趁着粮堆还不高时，拖着几十米长、拇指粗的测温电缆在仓内布线。电缆里包裹着钢丝，死沉。他得把它沿着预定路径铺好、固定，确保每个传感器都在设计位置。 这仅仅是开始。真正的考验是“拉线”。 粮堆深处的测温电缆，其线头最终要汇集到挂在仓库墙壁或柱子上的“测温分机”（采集器）。他需要扛着梯子，在满是灰尘的仓房里，将几十根从粮堆里引出的线，一根根对号入座，拧到分机箱内的接线端子上。接错一根，整个回路的数据都可能乱掉。 这还没完。仓库里几十台这样的分机，还需要用更粗的“通信总线”（RS-485线）手拉手串联起来，最后拉到机房，接入一台专用电脑。 这，才是他口中“从杆子末端拉出数据线，连接到远处的分线器上”的真实图景：​ 那不是在粮堆上现插现拉的潇洒，而是在高温、高粉尘环境下，重复千百次的枯燥、负重且必须精准的体力与细心活。线要拉得横平竖直，接头要拧得牢靠，还要防鼠咬、防磨损。 刚开始，他觉得这工作充满了技术仪式感。干久了，日复一日地扛电缆、爬高、接线、测通断，只剩下一个字的感受：累。一种被庞杂的物理线缆和复杂现场环境反复折磨的、沉甸甸的疲惫。 然而，正是这种疲惫，让他对“可靠”二字有了刻骨的理解。他见识过雷雨天后烧毁一片的电路板，处理过因一个接头松动导致整仓数据瘫痪的故障，也深知那台机房里孤零零的电脑，就是整个系统最脆弱的“大脑”。 二、技术跃迁：从“有线”到“无线” 我朋友后来参与实施的，正是那套用来取代人工的有线测温系统。它的核心是用预埋测温电缆取代了人工铁钎——技术人员在粮堆中预埋专用电缆，每根电缆上集成数十个温度传感器，像“神经末梢”一样分布。数据通过RS-485总线手拉手串联，即设备像糖葫芦一样串在一条总线上，一个接一个。最终汇总到仓外的监控主机。 除了传统的平房仓，现代化的粮库越来越多地采用立筒仓（圆仓）。这种仓体高大，粮食像瀑布一样从顶部灌入，依靠底部的锥形漏斗和出粮机实现自动化出粮。 在这里，测温电缆不再是“蛇形”铺在底部，而是像垂直的琴弦一样，从仓顶的采集器一直垂到仓底。采集器不再藏在灰尘满布的机房，而是直接安装在仓顶的防雨箱里，通过无线模块将数据发送到云端。 这种结构，让粮仓从“体力活”彻底变成了“自动化工厂”。 再回到我朋友的测温系统，这解决了人工爬仓的问题，但带来了新的、更复杂的麻烦。 当时觉得这套系统很先进，但现在回想，它太“重”了： 怕雷击：几百米纵横交错的485总线，成了感应雷的“引雷针”，雷雨季后，分线器经常烧坏一片。 维护难：专用的监控电脑不能死机，SQL数据库一旦损坏，几年的历史温度数据可能全丢。 数据孤岛：粮库主任想看一眼温度，必须跑到那个满是灰尘的专用监控室。 工程浩大：布线、穿管、调试，一个仓的改造就需要数周，成本高昂。 真正的变革，发生在物联网和无线通信普及之后。 新一代的“黑盒”采集器出现了。它只有巴掌大小，却集成了主控、4G模块和无线传输功能。它直接读取测温电缆的数据，通过MQTT协议将数据打包成JSON格式，一跳直达云平台。 粮库管理员在办公室，甚至用手机，就能看到整个粮堆的立体温度云图。系统自动分析、自动报警。 免布线：每个仓门口挂一个4G黑盒，直接对接原有的分线器。省掉了跨仓位、跨建筑的数千米复杂布线工程。 云端大脑：不再需要机房那台脆弱的专用电脑，数据直接上云，永不丢失，随时随地可查。 三、黑盒的定位：避开红海，寻找蓝海 在深入了解行业后，我发现粮储智能化其实是一个典型的“双轨制市场”。 大公司的“铁桶阵”：资质与工程的护城河 国家级粮储库、大型央企的智能化改造，是标准的“重工程”市场。它被几家头部企业垄断，依靠的是强大的工程化资质（如机电安装、系统集成）和专用设备（如光纤测温、工业级5G网关）。这些方案性能极高，但成本也极其昂贵（单仓改造费用动辄数十万），且施工周期长，需要专业工程队进场。 我的“黑盒”逻辑：低成本与快速响应 我开发的这个黑盒项目（基于ESP32等开源硬件），从一开始就没打算去冲击那个“铁桶阵”。我清醒地认识到，在需要军工级可靠性的战略储备库，我的方案无法与那些天价的专用设备竞争。 黑盒的核心价值在于“降维打击”与“普惠”： 目标市场：中小型粮库、地方储备点、合作社、个体储粮户。这些场景对成本极度敏感，无法承担大型工程的费用，也无需那么严苛的可靠性。 核心优势：极致低成本（硬件成本可能只有大公司方案的百分之一）和极速部署（即插即用，一个人半小时就能装好一个仓）。 价值主张：用“够用”的可靠性，解决“有没有”的问题。对于绝大多数只需要基本温湿度监控、异常报警功能的用户，黑盒是让他们迈入数字化门槛的唯一可行选择。 结语：让技术回归解决问题的本质 技术不应只是大公司的专利和豪华包装下的奢侈品。我的黑盒项目，源于“插钎子”的汗水，目标是证明一件事：在那些大公司不愿弯腰、传统方案贵得用不起的“边缘地带”，廉价的芯片和开源的智慧，同样能默默守护好每一粒粮食。 这不仅是技术实现，更是一种让技术回归普惠、解决真问题的尝试。 四、我的“黑盒”：从痛点里长出来的解决方案 “虽然已离开粮储行业多年，但那些亲自插下的钎子，让我深刻理解了RS485总线的‘脾气’、雷击的刁钻、还有现场对‘简单可靠’的极致渴望。”——这种浸入式的场景理解，是我开发这款“黑盒”固件最硬的底气。 它不是一个实验室里的玩具，而是为了解决 “老旧工业设备低成本上云”​ 这个具体痛点而生的 “数字化插件”​ 。它目前是一个稳定的Modbus/RS485转MQTT网关固件，未来可以扩展为支持多种协议、具备边缘计算能力的核心。 未来黑盒可以集成LoRa，LoRa 最大的优势在于极强的穿透能力和超长的传输距离，非常适合“密闭、大跨度”的粮仓环境。在粮仓这种密闭、充满金属设备和粮堆的环境下，LoRa 依然表现出色。相比于 4G/NB-IoT 在密闭环境信号较弱的特点，LoRa 的信号能够穿透厚厚的墙体，深入到粮堆内部。配合无线测温探杆，使用电池以及太阳能电池板，彻底免布线。 关于合作： 我个人专注于核心固件的研发、算法优化与开源社区建设。硬件生产与制造，我与专业的工业设计伙伴合作，以确保设备的出厂品质。我相信，专业的人做专业的事，才能把产品做到最好。 最终结语 从“汗滴禾下土”的插钎巡检，到“数据云中走”的智能值守，变的不仅仅是工具，更是守护粮食安全的思维与模式。 我朋友的故事，可能只是大时代里一个很小的注脚。但如果这个源于亲身痛苦、成于开源技术的“黑盒”项目，能帮助到某个正在为粮仓温控发愁的中小业主，或者给某个在工业物联网领域摸索的开发者一点启发，那么，那些年在粮堆上流过的汗，就算有了超越它本身的价值。 技术，理应如此踏实而有温度。 后记与邀请 如果你也有过类似的工业现场“血泪史”，或正在寻找低成本的老旧设备数字化方案，欢迎交流。关于“黑盒”项目的固件核心进展、协议文档与配置字典，我将在爱发电https://afdian.com/a/modujson​ 持续同步与更新。

一、 项目愿景：让设备上云，像接线一样简单 新的一年，新的计划，我们致力于为工程师、创客及小团队，打造一套开箱即用、稳定可靠的工业物联网数据采集方案。你无需深究复杂的协议栈，只需聚焦业务，即可让传统设备轻松上云。 本项目的核心价值在于： 协议翻译官：打造一个高性能的“中间件”，将底层的Modbus协议（支持RS485/TTL）无缝转换为上层的MQTT协议，打通设备与云端的“最后一公里”。 软硬解耦：不绑定特定硬件。无论是WiFi环境（ESP32）还是4G环境（Cat.1模组），只要具备基本通信能力，软件就能赋予其“智能”，提供极大的硬件选型自由度。 解决技术断层：解决有业务需求但没有研发实力的小团队（如硬件工程师、创客、小厂），本项目提供了一种低成本解决方案。它只需通用开发板，就能实现数据采集和上云，花小钱办大事。 二、 技术架构：三位一体的全栈实现 为确保方案的极致稳定与高度可扩展，我们采用“固件 + 配置工具 + 演示端”的三位一体架构，确保方案的完整性与专业性。 核心固件（“翻译官” - 逻辑版） 固件架构：采用分层架构设计，硬件抽象层隔离具体芯片与通信接口（如RS485/TTL），实现核心逻辑与硬件的解耦；协议栈层实现完整的Modbus协议栈（主/从站，RTU/TCP），并进行高效、健壮的JSON封装；服务层内置MQTT客户端，负责可靠的数据上传、断线重连与本地缓存；配置管理层，通过Rust编写的PC工具下发设备配置，实现软件定义功能。 技术栈：采用C语言开发，优先实现裸机（No OS）逻辑版本，确保在资源受限的MCU上也能稳定运行，降低用户使用门槛。 功能：负责实时采集Modbus寄存器数据（如电压、电流），并根据配置的倍率进行数据转换，最后通过MQTT协议将数据打包上传。 PC配置工具（“指挥官” - Rust版） 技术栈：使用Rust语言开发，利用其内存安全特性，确保配置过程绝对可靠，工具长期运行不崩溃。 功能：提供图形化界面，用户可轻松配置通信模式、寄存器地址、倍率等参数。支持通过串口（USB转TTL） 进行固件刷新与参数下发，解决现场实施难题，无需复杂的网络配置。 数据演示端（“仪表盘”） 技术栈：微信小程序。 功能：扫码即可查看实时数据曲线与数值面板，直观验证数据上云效果，方便现场调试与演示。 三、 当前状态：诚邀你，成为“共创者” 项目正处于核心研发阶段，当前全力攻克裸机版本，实现通信方式支持WiFi和4G的Modbus RTU（串口）协议的稳定性与性能。它适合简单应用，保证运行稳定。我们相信，最好的产品源于真实场景的千锤百炼。 未来会研发通信方式支持LoRa、以太网的Modbus TCP，以及FreeRTOS多任务版，用于解决需要同时处理多路数据采集，复杂业务逻辑的高端场景。 因此，我们发起此次共创计划： 你的支持，将直接转化为测试硬件（ESP32、各类Modbus传感器），用于极限环境下的兼容性验证。 你的设备，可以寄来成为我们的“适配样本”，共同完善设备库。 你的反馈，将直接塑造产品的下一个版本。 四、未来承诺 当固件通过大量真实场景验证，达到工业级稳定标准后，我们将正式申请软著，并启动授权售卖。所有共创阶段的支持者，都将依据历史贡献，获得丰厚的升级折扣与永久优先支持权。 我入驻了爱发电，更多详情内容请查看：https://afdian.com/a/modujson

在移动应用分发、文件共享等场景中，我们常常会遇到这样的困境：云存储平台（如阿里云OSS、腾讯云COS、蓝奏云等）上传的文件地址一旦生成就无法修改，但客户端版本频繁迭代时，每次更新都需要重新生成下载链接和二维码。用户端需要不断更新访问入口，体验极差。我就碰到了此类问题，在上一篇文章，我介绍了自己的客户端，并分享了下载地址。但我发现当我需要重新升级版本时，已经生成的地址将无法变更。在我的文章中，我直接使用了文件下载地址。这就让我急需解决如何实现"一次分发，永久可用"的优雅方案？Nginx反向代理配合301重定向，正是解决这一痛点的利器。 一、问题根源：云存储的地址锁定机制 大多数云存储服务采用"对象存储"模式，文件上传后生成固定URL，该地址包含存储桶名称、地域、文件路径等不可变信息。这种设计虽然保证了数据一致性，却带来了分发难题：每次版本更新，开发者必须重新上传文件、生成新地址、制作新二维码，用户需要重新扫描或获取新链接。对于频繁迭代的应用，这种重复劳动不仅效率低下，更可能因用户未及时更新而影响使用体验。 二、解决方案：Nginx重定向的架构设计 核心思路是地址解耦——将"物理存储地址"与"用户访问入口"分离。通过Nginx服务器作为中间层，用户始终访问固定域名，Nginx根据配置将请求重定向到实际的云存储地址。当文件更新时，只需修改Nginx配置中的目标地址，用户端的访问入口保持不变。 具体架构如下： 用户 → 固定域名/短链接 → Nginx服务器（301重定向） → 云存储实际地址 这种设计实现了三个关键目标： 入口稳定性：用户扫描的二维码或保存的链接永久有效 维护灵活性：后台地址变更只需修改Nginx配置，无需重新分发 成本可控性：Nginx只做重定向，流量消耗极低，普通云服务器即可承载 三、技术实现：从配置到部署 环境准备购买一台云服务器（1核1G配置即可），安装Nginx，将自有域名解析到服务器IP。推荐申请SSL证书启用HTTPS。 Nginx配置示例 server { listen 80; server_name your-domain.com; # 方案一：直接重定向 location /download/app.apk { return 301 https://bucket.oss-cn-region.aliyuncs.com/v2.0/app.apk; } # 方案二：通配符匹配（更灵活） location ~ ^/app/(.*)$ { rewrite ^/app/(.*)$ https://new-bucket.oss-cn-region.aliyuncs.com/$1 permanent; } } 重定向类型选择 301永久重定向：搜索引擎会更新索引，客户端会缓存重定向结果，适合生产环境 302临时重定向：每次请求都会重定向，适合测试阶段频繁变更的场景 二维码生成 将固定地址（如https://your-domain.com/app/v2.0.apk）生成二维码，用户扫描即可下载。后续版本更新时，只需修改Nginx配置中的目标地址，二维码无需重新制作。 四、方案优势与注意事项 核心优势 零用户感知：用户无需关心后台地址变化 维护成本低：修改配置即可，无需重新上传二维码 扩展性强：可支持多版本共存、灰度发布等复杂场景 兼容性好：支持各种客户端（浏览器、APP、微信等） 实施建议 测试先行：在测试环境验证重定向逻辑，确保目标地址正确 监控告警：配置Nginx日志监控，及时发现重定向失败问题 备份机制：保留旧版本配置一段时间，避免新配置问题影响用户 性能优化：虽然重定向开销小，但高并发时需确保服务器性能 五、总结 Nginx重定向方案将复杂的地址管理问题转化为简单的配置变更，实现了"一次分发，永久可用"的理想状态。这种解耦思维不仅适用于文件分发场景，在API网关、微服务路由等场景中同样具有借鉴意义。对于中小型项目而言，这是成本最低、效果最直接的解决方案，值得每一位开发者掌握。 最后推荐一下我的豆子域名管家客户端，这个客户端可以解决域名证书到期忘记更换证书的问题。我是为了解决这个问题而想出来的这个方案。这是我的新的下载地址：https://lab.91demo.top/b011 这样当我修改下载地址时，我不用再变更这个地址，比如我最近刚刚优化了域名扫描逻辑，上传了新的版本，它生成了一个新的下载地址。 当然这个方案还是有一点瑕疵，它需要每次更新都登录服务器修改nginx配置文件，这对于非技术人员非常不方便。后期我还有再次进行优化，我将使用小程序完成新地址的更换。大致思路如下：开发一个轻量的Go服务，提供接口给小程序提交新的地址，然后保存编号和新地址到数据库，例如上面的b011是编号，它对应新的下载URL地址。然后使用Nginx代理这个服务，当用户访问b011时查询它的URL地址，然后返回301和新的地址。这样就不用每次都登录服务器修改Nginx配置，在手机上也方便操作，提供了极大的便利性，也可以交给非技术人员进行维护。

我使用go写了一个http转WebSocket服务，这是一个命令行程序，双击可以直接运行，今天，有个新的需求，需要将这个命令行程序转为dll，然后供第三方使用。 1，改造程序 这个命令行程序很小，核心逻辑就是启动了一个HTTP服务，然后接收连接，然后通过WebSocket将内容转发出去。所以，在调整为dll时，仅仅需要导出两个函数即可。 1，StartServer，启动http服务，监听端口地址。因为不能阻塞，所以需要在监听服务时使用go方法启动一个携程。 2，StopServer，关闭http服务，需要提供给第三方，当它关闭时，需要调用它，释放监听地址等资源。 下面开始改造代码： package main import "C" // 必须导入 C 包 import ( // ... 原有导入 ... ) // 保持原有的全局变量和函数逻辑 (例如transDataGet, connWs 等) // 需要注意下面的//export这中间不能有空格，否则无法导出头文件 //export StartServer func StartServer() { // 将原本 main 函数里的逻辑放在这里 gin.SetMode(gin.ReleaseMode) r := gin.New() // ... 注册路由 ... r.Run("127.0.0.1:9988") } // 必须保留一个空的 main 函数 func main() {} // 其它参考StartServer，如果需要导出，一定要添加//export 2，编译命令 我是在windows环境，需要安装cgo环境，我安装了Mingw-w64支持C编译环境，执行以下命令： go build -buildmode=c-shared -o trans.dll main.go 执行后会生成trans.h和trans.dll两个文件。 3，验证dll 除了一些可以查看dll的工具外，还可以使用第三方语言进行测试。例如我这里使用Python。 import ctypes import time lib = ctypes.CDLL("./trans.dll") lib.StartServer() print("服务已在后台启动...") time.sleep(10) # 模拟第三方程序运行 lib.StopServer() print("服务已关闭") 4，再次优化代码 当实际测试的时候，我发现它会阻塞调用者，为了解决这个问题，我们需要再次改造程序。将启动服务改为非阻塞模式。将Gin的启动逻辑放入协程，并利用http.Server提供的Shutdown方法来实现优雅退出。 ...

域名过期导致业务中断、流量缺失、品牌受损的案例比比皆是。手动记录域名的到期时间？是否会忘记，漏看？ 我以前曾介绍过，我在微信小程序实现了域名证书监控功能。但是担心隐私，功能限制。这次我带来了豆子域名管家，本地化运行。 经过数月的规划和开发测试，豆子域名管家终于可以使用了。这是一款完全本地运行、支持批量导入管理以及可以企微和钉钉通知的域名证书检测工具。旨在解决域名过期监控难题。 特性 传统方式 豆子域名管家 运行方式 依赖云端服务 纯本地运行，数据不出本地 批量处理 手动逐个查询 一键导入，批量删除 通知渠道 单一（邮件/短信） 钉钉+企微双通道，支持Markdown格式 自定义提醒 固定时间提醒 可配置通知时间，提前预警天数 系统集成 无 系统托盘常驻，后台静默运行 隐私安全 数据上传第三方 域名数据和配置数据存本地 技术架构亮点： 工具基于Wails3框架构建，采用Vue3+NaiveUI前端技术栈，确保界面简洁美观，交互流畅，支持暗黑/浅色两种主题。 本地证书检测引擎，直接调用系统网络库进行TLS检测，无需依赖外部API。 多线程并发处理，使用go的特性批量进行域名检测。 跨平台兼容：支持Windows、macOS、Linux系统。 配置持久化，所有配置本地存储，重启后自动恢复。 支持域名证书检测，域名到期时间检测。 软件运行界面预览： 控制面板 配置页面 基本操作指南： 1，导入域名我们需要把要监控的域名按行录入到txt文档中，可以在软件配置界面下载示例模板，当准备完成后，选择刚才的文件，然后验证。没有问题后，点击确认导入即可。 2，配置机器人目前工具支持钉钉机器人和企业微信机器人，支持Markdown格式消息，可以查点击推送预览效果按钮查看推送效果。当输入机器人配置后，可以验证测试，当收到消息后说明配置成功，点击保存即可。可以同时配置企微和钉钉。这样会同时推送两份通知。 3，配置推送通知策略目前工具扫描调度间隔固定24小时，可以配置通知时间，和告警天数间隔。在通知时间，系统会将当天扫描的结果报表推送到机器人。如果用户更新某些域名证书后，可以在监控面板进行手动刷新。想查看效果，可以把通知时间设置为当前时间加几分钟，当到达时间后，将推送报表。确认无误后，可以调整为真正的推送时间。 4，系统托盘运行当完成域名导入和机器人以及通知策略配置后，可以关闭窗口，工具将自动缩放到系统托盘。如果需要退出，需要右键系统托盘退出。注意，如果退出工具，将不能监控域名，因为这是一个本地工具。所以需要工具长期运行。 5，监控面板监控面板的仪表板显示你的域名配置项统计信息，表格显示监视的域名列表。域名可以搜索，刷新以及删除。域名按照过期、告警、正常顺序排序。请查看最前面域名并及时处理。 工具按照自己的真实需求开发，如果你需要尝试，可以通过下方下载链接。目前仅提供了Windows版本。 https://91demo.top/b011 如果您有任何问题和建议，欢迎反馈和交流。

Mole 项目已经开源，打算把仓库在 GitHub Release 页面中发布各个平台的安装包/二进制（像 frp 那样），已经完成脚本，可参考.github/workflows/release.yml，这个用来记录实现过程与遇到的坑，便于自己回顾。 大致流程 查阅 GitHub Actions、goreleaser、actions/create-release、actions/upload-release-asset 等资料。 在仓库中写一个 matrix workflow，在 Windows / macOS / Ubuntu runner 上分别构建并打包。 修复构建中出现的依赖与环境差异问题。 将构建产物上传为 Release asset（先查找/创建 release，再上传各平台包）。 调试并保证上传在 Release 页面能看到各平台包。 今天遇到并解决的主要问题（按流程顺序） Ubuntu 图形库版本不一致 问题：教程写的是 libwebkit2gtk 4.0，但在新版 Ubuntu runner 上只能安装 4.1。 处理：在 CI 的 apt 安装里兼容 4.0 和 4.1（尝试 4.1，或用 || 逻辑兼容两种包名）。 wails3 安装地址写错导致安装失败 问题：go install 用错了模块路径，安装一直失败。 处理：修正为官方地址（例如 github.com/wailsapp/wails/v3/cmd/wails3@latest），并确保 GOPATH/bin 在 PATH 中。 wails3 的 -platform / -o 参数在我的环境不可用 问题：官方文档的参数在实际运行时报错或不生效（不能指定输出名）。 处理：不完全依赖 CLI 的跨平台参数，在对应 runner 上运行构建命令并从 bin/ 下输出文件打包；如有必要向 upstream 提交 issue。 macOS 的平台特有代码需要 build tag，而不是运行时判断 ...

如果你要开始项目开发，看看如下 Git 常用命令对你绝对有帮助。 在每次开发新功能时，拉出一个新分支，分支名称为开发的功能名称，格式为 func-xxxx。当开发的功能完成并测试没有问题后，合并到主分支。 当在开发新功能时，如果出现 bug，能够马上解决的，直接在主分支上修改，如果需要时间长，则新创建一个分支，格式为 bug-xxxx。当开发的功能完成并测试没有问题后，合并到主分支。 1，开发分支。 切换到 dev 分支，进行代码开发。开发完毕后，合并到主分支。 git checkout dev 2，合并到主分支。 git checkout master git merge dev git push origin master 3，主分支添加 tag，并发布到线上。 git checkout master git tag -a v1.0.0 -m "V1.0版本" git push origin v1.0.0 git push --tags 4，删除分支 git branch -d 分支名称 5，设置用户名和邮箱 git config --global user.name 你的用户名 git config --global user.email 你的邮箱 打标签 # 列出标签 git tag # 列出特定版本标签 git tag -l "v1.8.5*" # 创建标签 git tag -a v1.4 -m "my version 1.4" # 显示标签 git show v1.4 # 根据提交打标签 git tag -a v1.2 9fceb02 # 推送标签 git push origin v1.5 # 删除标签 git tag -d v1.4 # 检出标签，浏览使用 git checkout v1.4