既然不想买服务器，我就在边缘计算上动脑筋。这话说出来，我自己都觉得有点讽刺。2016年那会儿，我为了抢一个热点，能连夜租十台云服务器做爬虫集群，就为了那半小时的流量峰值。现在？连按月续费都觉得肉疼，不是没钱，是心态彻底变了。
上个月把最后一个长期运行的爬虫监控服务停了。不是技术问题，是算了一笔账：它每个月帮我抓的数据，带来的潜在收益，抵不上那台2核4G的ECS费用。更关键的是，这种“监控-触发-响应”的模式，本质上还是在追着流量跑，太被动了。我就像个消防员，哪里起火扑哪里，永远在救急，永远在焦虑。流量来了兴奋半小时，流量走了空虚一整天。这种肾上腺素驱动的模式，我干了七年，真的干吐了。
所以这半年，我所有的精力都挪到了“边缘”。不是那个时髦的“边缘计算”概念，而是字面意思：把计算和逻辑，尽可能推到用户本地，推到浏览器里，推到那个不用我掏钱买服务器的环境里。最开始是逼出来的：客户有个需求，要定期处理一批Excel，但数据敏感不能上传。按老思路，我得写个后端API接收文件，处理，再返回。现在？直接用WebAssembly+IndexedDB，在用户浏览器里把活干了，关掉网页，一切烟消云散，我的服务器压力是零。
这思路一打开，就收不住了。以前做个工具，第一反应是“后端用什么框架，数据库怎么设计”。现在第一反应是“这逻辑能不能全在前端跑？数据能不能存LocalStorage？复杂计算能不能用Web Worker拆开？” 我翻出以前做的那些小工具，一个个重构。一个简单的SEO元标签检查器，原本需要后端去抓取页面源码，现在直接用Fetch API加上CORS代理（甚至教用户自己搭个免费的CORS-anywhere），检查逻辑全部用JavaScript在浏览器里跑。用户觉得快，我觉得省。
当然，代价就是前端的复杂度飙升。要处理各种浏览器的兼容怪癖，要面对用户本地环境的不确定性，网络断了怎么办？浏览器版本太老怎么办？这些在过去扔给后端统一处理的问题，现在全得在前端考虑。但这感觉很奇怪，像是一种更扎实的掌控感。我不再需要为一个可能突然涌来的流量峰值而过度配置服务器资源，也不再需要为API的并发限制和频率限制写一堆补偿逻辑。每个用户都自带“计算资源”，我的代码只是去协调和利用它。
昨天下午，就坐在窗边那个旧沙发上，看着外面那棵树的叶子一片片往下掉。脑子里没什么“感悟人生”，就是在想一个技术细节：怎么把Puppeteer的部分无头浏览器操作，通过CDN分发WebAssembly模块，在用户本地执行网页截图。这样连截图服务的服务器也省了。想着想着，天就暗了。楼下的车流声起来，屋里没开灯。
这种“边缘化生存”，某种意义上，是对我之前整个流量焦虑生涯的物理矫正。我不再追求服务的“永远在线”，而是追求工具的“开箱即用，用完即走”。我不再维护一个庞大的、需要我持续喂养的中心，而是制造无数个可以自我完成的端点。流量会过去，热点会冷却，但一个能解决具体问题、不依赖我服务器的小工具，它可能活得更久。就像那些落叶，腐烂了，成了土，明年那棵树还在那里。我要做的，是那棵树，而不是每年拼命绽放、一夜凋零的花。
半年时间，从想着“扩容、负载均衡、自动伸缩”，到琢磨“Service Worker的缓存策略、Web Crypto API的本地加密、浏览器的存储上限”，这个转变有点魔幻。但人踏实了。晚上睡觉前，不再会突然惊醒，想着服务器是不是挂了，爬虫是不是被反扒了。因为现在，根本没有服务器可挂。所有的风险和责任，都被我巧妙地、或者说“鸡贼”地，分摊到了每一个用户的浏览器标签页里。这算不算一种数字时代的“藏富于民”？
接下来，我可能会把这条路走到黑。把所有需要持久化、低频率的服务，都想办法“边缘化”。甚至开始看Cloudflare Workers和Vercel Edge Functions这些真正的边缘计算平台，它们按请求次数收费，对于低频工具来说，成本近乎为零。技术栈又要更新一轮，但这次的学习，没有以前那种“不学就被淘汰”的恐慌，更像是在给自己打造一个更轻便、更坚固的掩体。流量的大水漫灌过来，我可能就在这些边缘的缝隙里，活得挺好。
