最大的毛病就是懒，但又受不了重复劳动。尤其是几年前，被那个月底对账的活儿折磨得够呛。那时候我投资的玩意儿多，光是券商账户就有三个，再加上银行的各种理财，每个月非得花一个周末，盯着屏幕，把各种流水和盈亏数据往Excel里扒拉。要是哪个数据对不上，那就得再花半天去一个个核对。
扒拉了三年，我决定不干了。 我当时就想，这肯定能自动化，非得搞一个东西替我干活。这就是“我的猪公主”这个项目的起源，它不是个游戏，也不是个宠物，它是我的个人数据自动化管理系统，专门干这些又脏又累的活儿。
一、最初的折腾与失败（项目启动）
最开始的时候，我脑子热，觉得用爬虫能解决一切。我立马就动手，用Python写了十几个脚本。我的想法很简单：模拟登录，找到报表下载链接，抓数据，完事儿。
- 第一步：模拟登录。 这就花了我不少时间，各种验证码识别，搞得我焦头烂额。
- 第二步：抓取数据。 第一次跑起来的时候，那感觉简直是太棒了。一键运行，所有数据自动汇总。
但好景不长。银行和券商的网站三天两头更新界面。他们稍微改一下按钮的位置，或者把数据表格的ID换一下，我的脚本立马就瘫了，报错信息能堆满整个屏幕。修一次脚本，比我手动输入数据还费劲。这完全违背了我“偷懒”的初衷。
我意识到，我需要的不是一次性的脚本，而是一个能自己跑、能稳定运行、能处理异常的系统。必须把这个东西实体化，让它自己待着，自己去折腾。
二、猪公主的诞生（硬件与框架搭建）
我立马就去买了个树莓派，找了个旧的固态硬盘，给它装上了系统，搭了个轻量级的Docker环境。我把这个小机器通电的那一刻，它就成了我的“猪公主”，负责替我干那些我想逃避的活儿。
这回我学乖了，我不再依赖网页前端的结构。我的策略是：直接去抓取数据接口，或者绕过网页，监听数据包。
整个系统架构我是这么搭起来的：
- 数据采集模块： 负责定时（每天凌晨两点）去各个平台进行数据请求。这个模块我做了重试机制，如果请求失败，它会等十分钟再试，连试五次。
- 清洗与存储模块： 拿到原始数据后，立马进行格式化处理，然后统一扔进我的本地MySQL数据库里。
- 看板模块： 用一个开源的仪表盘工具，连着我的数据库，让我随时能看到最新的汇总结果。
系统是搭起来了，大部分银行的数据还好说，最让我头疼的是那些券商的手机APP数据，特别是那些私有的、不公开的接口。
三、最新更新日志：搞定加密数据流
最近这一个月，我一直在攻克一个大难题，也是这回《我的猪公主_更新日志_最新》的核心内容：如何稳定抓取某A券商的实时持仓变动数据。他们那个API藏得跟什么似的，根本不给你直接调用的机会。之前我用的都是模拟APP请求头的土办法，但他们这回更新后，数据传输直接上了双重加密，我的老办法彻底失效了。
我折腾了快一个月，看了无数的抓包工具和解密教程。 我试过在手机虚拟机里跑，试图拿到密钥，但都失败了。后来我琢磨着，既然我拿不到密钥，能不能绕过密钥，直接从数据流的底层去抓，只解析那些我需要的、稳定的数据字段？
我的解决办法是：写了一个专门的中间件，我叫它“拦截猪”。
我没有去追着APP的变动跑，而是通过设置一个本地代理，让“拦截猪”作为唯一的流量出口。每当APP请求数据时，“拦截猪”就像个中间人，它能看到所有加密后的网络包。虽然我解不开密文，但通过观察大量的请求和响应，我发现了几段数据包的特征码是固定的，而且是跟持仓信息直接关联的。
我花了两个礼拜，把这套解析逻辑写死在了中间件里。 它不再尝试解密整个数据包，它只负责识别特定特征码，然后将紧随其后的、长度固定的数据段剥离出来，扔进我的数据库。这就完美避开了频繁变动的加密算法。
新的数据采集模块已经上线一周了，跑得非常稳定。每天早上八点半，它准时把最新的盈亏数据扔到我的看板上，误差率几乎为零。这下好了，我彻底解放了，月底再也不用盯着Excel表格发愁了。我的“猪公主”终于替我扛下了最难啃的骨头，我现在的任务就是享受成果，然后等下一个平台的更新，再来一次新的折腾。