说起《我的猪公主》这个项目，我跟你说，那简直就是一部血泪史，前前后后我折腾了快一年，大大小小的版本迭代了好几十次，但这回的“最新版本”是真的稳了，我已经跑了快三个月，没出任何幺蛾子。今天就从头到尾给各位老哥老姐们捋一捋，我是怎么把这坨东西给做出来的。
第一阶段：心烦意乱，被迫入坑
我的“猪公主”是头迷你小香猪，吃得多拉得多，最关键的是，吃药和定点喂食的时间必须准。以前我就是拿个小本本手写记录，但人总有糊涂的时候。有一回，因为药量记错了，公主闹了一天的肚子，把我气得够呛。我当时就决定，不能再靠人脑和烂纸片了，必须搞个系统来管它。
我翻箱倒柜，把吃灰好几年的树莓派给挖了出来。一开始我的想法很简单，就是搞个简单的Python脚本，连上个摄像头和几个温度湿度传感器，能把数据扔到我本地的服务器里就算完事。我花了一个周末，用Django搭了个简陋的后台，前端就是最原始的HTML，连CSS都懒得写。我把那堆破烂传感器焊用胶带缠在猪圈边上，自以为大功告成。
结果？我装上去不到三天，系统就崩了。为猪公主太能拱了！它用鼻子一拱，所有的线头全散了，传感器也沾满了泥巴，数据全他妈是乱码。我气得差点把树莓派砸了。那次失败，让我明白一个道理：你做的东西再如果物理环境扛不住，一切都是空谈。
第二阶段：推倒重来，聚焦核心
第一次的失败让我改变了思路：少搞那些花里胡哨的监测，先解决最关键的——定时定量喂食和用药提醒。我把所有的技术栈全部推倒重来。
我决定放弃Python那种“大而全”的框架，转头选择了Go语言作为后端，就因为它跑得快，占资源少，而且编译出来的执行文件小小的，扔到RPI里简直完美。我重写了所有跟数据库交互的逻辑，只保留了最核心的三个功能：
- 自动喂食开关：连接了一个智能继电器，直接控制食槽的放料。
- 定时提醒列表：设置用药和驱虫时间，到点就给我手机发通知。
- 简易日志：只记录喂食是否成功，以及公主的体重（这是我手动每天称重后输入的，没敢再装自动称重传感器，怕被拱烂）。
前端UI这回我用Vue随便扒拉了一个模板，纯粹是为了实现操作便捷。我花了三天三夜的时间，把这个V2.0版本的系统给硬生生赶了出来。这回我学聪明了，我用铁皮箱子把RPI和继电器锁得严严实实，所有的线都走了钢管保护，看你公主还怎么拱！
第三阶段：持续优化与“最新版本”实现
V2.0跑起来还不错，但问题很快又来了。虽然功能实现了，但Go程序总在凌晨三点多莫名其妙地抽风，需要手动重启。我盯着日志看了好几天，才发现是内存泄露，虽然Go有垃圾回收，但我代码写得太糙了，有些协程没处理就一直占着内存不放。
我花了大量精力去优化这几段关键的喂食代码，把那些多余的缓存和日志记录通通砍掉，追求极致的稳定和轻量化。这个过程就像在做减法，每去掉一点冗余，系统的稳定性就增加一分。我把报错逻辑也改了，一旦喂食失败，它会立刻尝试重试，并且给我发短信通知，而不是单纯地发应用通知（应用通知有时候会漏掉）。
这回的“最新版本”——也就是V3.5——主要的改变不是加了什么新功能，而是对老架构的彻底加固和优化。我把数据库从SQLite换到了内嵌的BoltDB，因为它更轻，读写速度更快，而且文件级别的存储对我这种应用来说简直是无敌的。我又做了一层物理上的冗余，给继电器加了个手动物理开关，万一系统彻底挂了，我还能在手机没电的情况下用手去拉开关，确保公主不会饿肚子。
实践记录写到这，我发现最大的感触是：搞这种家用小项目，技术栈反而是次要的。重要的是你能不能抗住物理破坏，能不能快速应对各种突发的小故障，并把它变成一个无需维护的“傻瓜”系统。现在的V3.5，我基本上就是部署上去后，就彻底撒手不管了。它就安静地在那儿跑着，尽职尽责地服务我的“猪公主”。这种自己动手、完全掌握的感觉，真是太爽了！