做工具合集这事起源于我自己日常被两件事反复折腾一是写脚本时经常要临时存一点状态、同步一段JSON配置不想为这点小事专门起数据库二是定时任务跑完了结果和告警没法第一时间推到我手机上总要等跑完回去看日志。后来我陆续接触了一批免费的文本读写/在线通知API发现这两类服务组合起来几乎能覆盖个人开发者和小项目的大部分“轻量级基础设施”需求。这个工具收集的就是这些开箱即用的免费API。先说它能解决什么问题文本读写API让你在公网上直接存储和读取一段文本或JSON数据不需要服务器、不需要数据库发个HTTP请求就能完成读写在线通知API则能把消息实时推送到微信、iOS或浏览器像发一条短信一样简单。适合做自动化脚本的告警通知、轻量级的远程配置管理、多设备间的临时数据同步也适合做个原型验证一下想法在没有预算买云服务前先跑通流程。全文会从方案选型讲到具体调用到最后结合一个完整的监控告警脚本把两类API怎么配合用讲明白同时也会把我在实际调用中踩过的认证、超时、数据格式的坑都列出来。1. 项目概述一次搞懂“文本读写API”和“在线通知API”1.1 文本读写API到底在读写什么文本读写API顾名思义就是通过HTTP接口对远程的一段文本或JSON数据进行读写操作。你可以把它理解成一个“公网上的共享便签”——往上面写内容别人或者你自己拿着链接和凭证就能读也能覆盖写。我第一次用这类API的时候最大的感受是这东西把“持久化”这件事的门槛降到了零。以前脚本里要存状态要么写本地文件换台机器就没了要么起个MySQL/Redis太重了要么用云厂商的对象存储要去控制台开桶配权限。而文本读写API只需要一个URLPOST一次写入GET一次读取PUT一次更新核心操作全部是标准HTTP任何语言都能调。常见的免费文本读写服务有jsonblob、npoint、kvdb.io、getpantry这类。它们的使用体验大体类似无需注册或注册后拿一个token创建一条数据后返回一个唯一ID或URL之后对URL发起GET/POST/PUT/DELETE操作即可。存储的内容可以是一段纯文本、一组键值对也可以是任意JSON结构基本能满足“临时存储”和“轻量数据交换”两大类需求。有人可能会问和GitHub Gist、云存储对象有什么区别区别在于这玩意儿是“为API调用而生的”Gist本质是版本管理强调协作和记录对象存储要配SDK、配权限、处理大文件分片杀鸡用牛刀。文本读写API的定位就是——短小精悍的键值存储一次请求一次响应几毫秒搞定。1.2 在线通知API是怎么把消息推到手机上的在线通知API解决的是“我怎么第一时间知道脚本跑挂了/跑完了”这个问题。它的工作模式很统一你向一个HTTP接口发起请求请求里带上标题和正文服务端就会把消息推送到你绑定的终端上。按推送渠道区分主流的免费在线通知API大致有三类微信渠道以Server酱ServerChan为代表扫码绑定“服务号”后通过一个GET/POST请求即可把消息推送到微信里会以服务号消息的形式通知你。iOS渠道以Bark为代表iOS设备安装App后生成一个专属URL对这个URL发请求就能收到推送极其轻量。通用Push渠道以ntfy为代表支持订阅Topic发消息只需要一句话curl -d 你好 ntfy.sh/主题名Android、iOS、Web端都能收。这类通知API的价值不只是“收到消息”更重要的是它让你把“人”接进了自动化链路里。定时任务跑完了发一条“备份完成耗时5分钟”监控发现磁盘超过阈值立刻推一条告警到手机。人不需要盯着终端或控制台异常发生时你是被动接收方而不是主动巡检方。我在实际用下来还有一个体会通知API最适合的场景恰恰是“低频及时”。几分钟发一条甚至几小时发一条都没关系关键是发出去的那条一定要到。所以选型的时候我会格外看重送达稳定性而不是炫酷的功能。后面章节我会展开讲不同渠道的稳定性差异和取舍。2. 方案选型为什么我推荐这几种免费API2.1 文本读写API横向对比目前市面上免费的文本读写API不算多但各有各的性格。我挑了几个典型代表按我的实际使用体验做个对比。服务核心特点上手难度稳定性表现典型用途jsonblob无需注册POST即创建返回JSON blob URL极低公共实例偶尔限速快速存一段JSON、临时共享npoint可视化编辑JSON支持绑定自定义域名低稳定托管静态JSON配置kvdb.io纯KV存储接口极简极低稳定存状态、计数、开关值getpantry按Bucket管理支持多种数据格式低公共实例一般小型数据聚合我在早期项目里最常用的是jsonblob因为它的接口直觉到不用看文档POST一个JSON过去返回一个URLGET这个URL拿到数据PUT则为更新。如果只是想在两台机器之间同步一段配置它是最快的路径。但如果要被多个脚本长期频繁调用我反而会更推荐kvdb.io这类接口更克制的服务——它提供的是一个接近GET /values/key和POST /values/key的朴素KV语义不容易被JSON嵌套搞晕请求量上来后响应也相对稳定。2.2 在线通知API横向对比通知渠道的选择和你的使用场景强相关。我自己同时接入了Bark和Server酱因为它们解决的场景完全不同。渠道推送形式免费额度依赖条件适合人群Server酱微信服务号消息每天少量免费微信扫码绑定日常监控、告警PushPlus微信公众号消息有免费额度微信公众号关注群消息推送、批量通知BarkiOS系统推送无限一台iPhone安装App个人告警、快捷推送ntfy通用Push通知无限安装App或Web订阅技术玩家、多端通知如果追求的是“躺床上也能被叫醒”iOS端选Bark用系统推送通道锁屏就能看到不会再被App静默掉。如果追求“到微信就相当于到了”那就选Server酱或PushPlus扫码绑定后不需要装任何额外App消息直接进微信。这里面有个容易被忽略的点Bark这种自建服务式的通知API其实是需要你手动配置推送地址和密钥的。具体来说你要在自己的iOS设备上装好App拿到属于你的推送URL形如https://api.day.app/你的Key/标题/内容以后不管在服务器还是本地脚本里往这个URL发请求就行。推送通道走的是苹果APNs所以只要App活着消息就能到。2.3 为什么不建议自己搭一套不少读者看到这可能会想这些功能我拿一台云服务器甚至家里NAS都能自己实现为什么要用第三方免费API我的回答是分场景的。如果你已经有常驻公网的服务器而且你本身就很熟悉Web开发那自建确实可行自由度也更高。但绝大多数情况下我们只是想在“写一个10行脚本”时顺手把通知问题解决掉而不是又开一个新项目去维护。自己搭一套通知服务意味着你要处理公网域名/HTTPS证书、服务常驻、进程守护、消息队列、甚至App端推送证书维护。对于一个“只想在脚本跑完时收到一条消息”的需求来说这代价太高了。免费API的价值就在于把基础设施的复杂度完全外包你只管发HTTP请求。当然免费服务也有前提——不要拿它当生产级核心依赖。免费额度通常意味着速率限制、配额限制和“不保证可用性”。这也决定了它的合适位置个人工具、内部脚本、原型验证、非关键链路的辅助功能。3. 实操从注册到第一次成功调用3.1 文本写入三种API风格都试一试先说文本读写API我用一个场景来演示想在远程存一段JSON配置内容是{project: demo, owner: xiaoming}。jsonblob风格无鉴权POST创建jsonblob的接口是一套纯粹的REST风格创建和读写分步走# 1. 创建blob返回的响应头 Location 里带blob的完整URL curl -X POST \ -H Content-Type: application/json \ -d {project:demo,owner:xiaoming} \ https://jsonblob.com/api/jsonBlob执行后服务端会返回类似https://jsonblob.com/api/jsonBlob/1234567890这样的完整URL。这个URL就是你的数据身份证后续所有操作都基于它。# 2. 读取内容 curl https://jsonblob.com/api/jsonBlob/1234567890# 3. 更新内容PUT会整体覆盖 curl -X PUT \ -H Content-Type: application/json \ -d {project:demo,owner:xiaoming,status:running} \ https://jsonblob.com/api/jsonBlob/1234567890kvdb.io风格无鉴权但指定keykvdb.io把“存储”抽象得更直接你要先创建一个bucket然后在bucket下按key存值。# 创建一个bucket响应里返回bucket ID curl -X POST https://kvdb.io# 往bucket里写一个key curl -X POST https://kvdb.io/BUCKET_ID/mykey \ -d my-value # 读这个key curl https://kvdb.io/BUCKET_ID/mykey这种风格的好处是你不需要维护“创建时返回的URL”URL完全由你掌控bucket ID 业务key非常适合脚本里动态拼接。token鉴权风格带API Key部分服务要求你在请求头里带上凭证这也是最接近“正式API”的形式curl -X POST \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d {project:demo} \ https://api.example-json-store.com/v1/blobs提示无论选择哪种服务第一件事就是看它的鉴权方式。有的服务靠URL里的不确定性来防猜测比如jsonblob的随机ID有的靠Header里的token两者安全性模型差别很大。如果是临时数据无鉴权问题不大哪怕是半敏感的数据也建议至少选带token的服务。3.2 在线通知五秒推一条消息到手机在线通知API是所有工具里“性价比”最高的一个——你几乎不需要写代码就能用起来。我以Bark和ntfy为例展示“一句话推送”的威力。Bark推送iOS先在iPhone上装好Bark打开App后会看到一个专属推送URL格式类似https://api.day.app/你的Key。只要往这个URL发GET或POST请求就能收到推送。最简单的调用直接用浏览器打开链接都能触发# 直接推送一行文字 curl https://api.day.app/你的Key/数据库备份完成如果想带标题和分组curl -X POST https://api.day.app/你的Key \ -H Content-Type: application/json \ -d {title:监控告警,body:磁盘占用率超过85%,group:production}ntfy推送全端通用ntfy的写法更随意它干脆把主题名放在URL里谁订阅了谁收消息# 发送方一句话推给指定主题 curl -d 部署完成耗时3分钟 ntfy.sh/my-ci-topic在手机端装ntfy App订阅这个主题消息就到了。ntfy同时也支持标题、优先级、点击打开链接等参数通过Header或JSON字段控制。Bark和ntfy测试下来都很稳区别在于Bark走苹果系统推送通道锁屏即达ntfy的公共服务器在高峰期偶尔会有一点延迟但胜在不限设备不限平台。Server酱的微信推送Server酱算是国内玩告警的老牌方案了。它和前面两种最大的区别是绑定微信服务号推送效果是在微信里收到一条“服务通知”样式的消息不需要装App。# Server酱的Send接口 curl -X POST https://sctapi.ftqq.com/SCT_你的SendKey.send \ -d title磁盘告警 \ -d desp根分区使用率已超过85%请及时处理加密升级后的Server酱Turbo版通过SendKey鉴权SendKey本身需要在服务端保存别混进博客或公开仓库里——这在后面讲安全时会再次提到。3.3 用Python封装一个统一调用模块不管是文本读写还是在线通知直接用curl能跑通但放到项目里往往还是希望有一个Python封装统一处理超时、异常和重试。我日常的做法是写一个轻量模块把常见服务包进去这样任何脚本里from notify import send_notify就能用。# api_tools.py import os import time import requests from typing import Dict, Any TEXT_API os.getenv(TEXT_API, https://kvdb.io) TEXT_BUCKET os.getenv(TEXT_BUCKET, ) # 替换成你的bucket ID NOTIFY_BACKEND os.getenv(NOTIFY_BACKEND, bark) # bark/ntfy/serverchan def kv_write(key: str, value: str, retries: int 3) - Dict[str, Any]: url f{TEXT_API}/{TEXT_BUCKET}/{key} for attempt in range(retries): try: resp requests.post(url, datavalue, timeout5) resp.raise_for_status() return {ok: True, key: key} except requests.RequestException as e: wait 2 ** attempt time.sleep(wait) return {ok: False, error: kv_write failed} def kv_read(key: str) - str: url f{TEXT_API}/{TEXT_BUCKET}/{key} resp requests.get(url, timeout5) resp.raise_for_status() return resp.text def send_notify(title: str, content: str) - Dict[str, Any]: if NOTIFY_BACKEND bark: bark_key os.getenv(BARK_KEY, ) resp requests.post( fhttps://api.day.app/{bark_key}, json{title: title, body: content}, timeout10, ) resp.raise_for_status() elif NOTIFY_BACKEND ntfy: topic os.getenv(NTFY_TOPIC, my-default-topic) resp requests.post( fhttps://ntfy.sh/{topic}, datacontent.encode(utf-8), headers{Title: title}, timeout10, ) resp.raise_for_status() elif NOTIFY_BACKEND serverchan: send_key os.getenv(SERVERCHAN_KEY, ) resp requests.post( fhttps://sctapi.ftqq.com/{send_key}.send, data{title: title, desp: content}, timeout10, ) resp.raise_for_status() return {ok: True}这个封装的关键在于所有外部HTTP调用都设置了timeout避免脚本因为第三方服务无响应而永久卡死重试采用指数退避原则第一次出问题等2秒第二次等4秒避免阶梯式重试把服务打死。4. 完整落地一个带告警的服务器监控脚本4.1 脚本整体设计有了文本读写API和在线通知API就能组合出一个典型的自动化闭环定时检查服务器磁盘使用率把状态写入远程文本存储同时在超过阈值时把告警推送给手机。整体流程图不需要复杂——脚本启动后做三件事读取上次的状态从文本读写API拉取用于对比和趋势感知采集当前磁盘使用率与阈值比较把当前状态写回远程存储如果触发阈值调用在线通知API推送告警如果恢复正常再发一条恢复通知。这里的设计逻辑是状态数据本身是“异步”且“可追溯”的。你不仅要让脚本在出问题时喊一嗓子还要让脚本之外的人包括未来的你能回看一段时间内的数据变化所以每次运行的状态都持久化到远程文本存储里比单纯看几条通知更直观。4.2 核心代码实现# disk_monitor.py import os import time import requests from api_tools import kv_write, kv_read, send_notify DISK_THRESHOLD float(os.getenv(DISK_THRESHOLD, 85)) HOST os.uname().nodename def disk_usage_percent(path: str /) - float: stat os.statvfs(path) total stat.f_blocks * stat.f_frsize free stat.f_bfree * stat.f_frsize used total - free return round(used / total * 100, 2) def run_check(): usage disk_usage_percent() last_key fdisk:{HOST} # 读取上次状态 try: last kv_read(last_key) previous_usage float(last) except Exception: previous_usage 0.0 # 写入当前状态 kv_write(last_key, str(usage)) # 超过阈值且尚未告警过 if usage DISK_THRESHOLD: send_notify( f[磁盘告警] {HOST}, f当前使用率 {usage}%已超过阈值 {DISK_THRESHOLD}%。 ) elif previous_usage DISK_THRESHOLD: send_notify( f[磁盘恢复] {HOST}, f当前使用率已回落到 {usage}%。 ) if __name__ __main__: run_check()这个脚本看起来简单但有一些细节值得注意。首先是“去重告警”机制。如果不用远程状态记录上次是否告警过那么每次cron执行都会触发一次告警磁盘持续超过阈值时手机就会被轰炸。现在通过读写历史状态脚本能判断“上一轮是否已经告警”从而只在状态翻转时发消息避免重复打扰。其次是恢复通知的价值。很多人只做告警不做恢复导致一次磁盘飙高后明明解决了手机里却没有“恢复正常”的回执。加入恢复通知后状态机就完整了告警、恢复都能感知。4.3 配置crontab定时执行脚本写好后用crontab定时执行最简单的方式是每分钟检查一次* * * * * cd /opt/scripts /usr/bin/python3 disk_monitor.py /var/log/disk_monitor.log 21环境变量需要通过crontab的env或写进脚本里加载。这里强烈建议不要用exports写死而是维护一个.env文件并用python-dotenv加载或者直接在crontab里用env KEYvalue形式指定。跑一段时间后你会发现这套组合拳的价值正常情况下你完全感知不到脚本在运行出问题时手机第一时间响起问题解决后你还能通过远程文本存储拉取历史数据确认故障时间段。4.4 验证是否真的通脚本跑起来后第一步验证我建议这样做手动设置一个很低的阈值比如5%确保必然触发看手机能不能收到告警推送然后再把阈值调回正常值跑一轮看能不能收到恢复通知。这一步能一次性验证文本读写的状态存取、通知API的推送链路、以及“状态翻转消息不重复”的逻辑是否正确。提示在第一次联调时我给自己的建议是——用print把kv_write和send_notify的HTTP响应完整打出来而不是只看有没有收到手机通知。因为如果推送URL配置错了服务端会返回400/404只有看响应体才能快速定位光等手机通知是盲等。5. 常见问题与排查技巧从401到连接断开5.1 401 Unauthorized到底是谁错了在所有API调用错误里unexpected status 401 unauthorized: incorrect api key provided可能是最常见的。文本读写和在线通知API遇到401原因不外乎三类API Key填写错误或已被篡改比如从环境变量里没读到值取了空串密钥过期、被重置或权限范围变了服务方要求的鉴权方式不是你想的那种有的是Bearer Token有的是自定义Header有的是URL路径里带参数。排查时我一般按这个顺序来先用curl裸调一次把响应完整打出来确认是服务端拒绝还是客户端没带对Header检查读取的环境变量是不是空的常见情况是shell里没export或.env文件里key名错了检查密钥是否包含额外空白字符复制粘贴时极易带入换行符或空格如果服务支持去后台重新生成一个Key试试不要在原Key基础上猜。我踩过最经典的坑是把Authorization: Bearer sk-xxx里的Bearer写成了Baerer服务端直接返回401。这类“肉眼很难发现但一查就明白”的问题唯一的解决思路就是别猜看响应体。5.2 连接断开和超时怎么处理免费API跑得多了另一个高频痛点是网络层错误典型的有connection dropped (econnreset)、connection lost mid-response、404/timeout。这些报错的原因通常集中在三块本地网络到目标服务器的链路不稳定目标服务的限流策略目标服务本身的波动。尤其是免费服务经常会在高峰期对突发流量做丢弃处理连接就是会被reset。针对这类问题的实操经验我的建议是“三层防御”第一层所有HTTP请求都设置超时。Python的requests默认没有超时一个服务不响应会把你的脚本挂住必须显式传timeout5之类的参数。第二层对可重试的错误网络不通、5xx做指数退避重试。退避公式wait base * 2^n从第0次失败开始wait分别为1、2、4、8秒最多重试3次。这比固定间隔重试要温柔得多。第三层对最终失败的结果做降级处理。比如通知推送连续3次失败不要直接丢弃可以把消息写到本地文件或远程文本存储里等下一次轮询时再补发。这样即使API临时性不可用消息也不会彻底丢失。5.3 数据格式与编码问题文本读写API遇到中文内容时最容易踩的坑是编码和Content-Type。以Bark为例如果直接在URL里拼中文不经过URL编码大概率会收到乱码或直接推送失败。正确做法是用POST请求把{body: 磁盘告警...}放在JSON里由requests自动处理编码。ntfy的curl写法也要注意Content-Type默认情况下curl -d会用application/x-www-form-urlencoded如果内容里包含特殊符号最好显式用--data-binary结合UTF-8编码。另一个问题是JSON序列化的格式。Python的json.dumps默认不保留非ASCII字符如果你直接拼接字符串而不是用ensure_asciiFalse中文会被转成\uXXXX传输过程中虽然语义一致但排查日志时会很痛苦。建议在调文本读写API时统一用json.dumps(data, ensure_asciiFalse)或者在读回时做一次json.loads。至于400 this models maximum context length这类和LLM context相关的报错虽然和文本读写API不算直接同类但它揭示了一个通用思维任何API都有请求体限制。文本存储API对小JSON没问题但如果你拿去存一个整库导出就会触发服务端的体积上限。所以不要拿KV服务当文件服务器用超过几MB的内容应该另寻对象存储。6. 安全与实用技巧密钥别裸奔调用别失控6.1 密钥管理的正确姿势使用带鉴权的API时最危险的做法就是把Key硬编码进代码里然后代码一不小心被推到公开仓库。我在踩过一次仓库泄露的坑之后总结了一套保守的存放方案本机开发放在.env文件里用python-dotenv加载.env必须写进.gitignore服务器部署放在crontab的export段落或者systemd service文件的EnvironmentFile里需要共享给团队尽量通过密钥管理工具或配置中心下发至少也要做到按环境隔离不能一个Key走天下。API密钥一旦怀疑泄露第一件事就是立即在服务端后台吊销并重新生成。对免费API服务来说Key被滥用可能带来封号风险平时别心疼该重置就重置。6.2 调用频率与配额控制免费API普遍有隐性的速率限制比如Server酱免费版对单日发送条数有上限Bark虽然不限量但也不适合高频轰炸。实际使用中我给自己的内部规范是通知类API一分钟内同一个主题最多发1条超出的消息合并成摘要再发文本读写API单条数据控制在1MB以内每秒请求数不要超过1次也够用定时任务所有脚本的轮询频率默认从5分钟起步必要时再缩短到1分钟。控制频率还有个好处把自己的调用行为约束在免费服务的合理区间减少被临时限流的概率也避免影响同一公共实例下的其他用户。6.3 组合玩法把免费API变成自己的“自动化积木”单个API看着不起眼但组合起来玩法就多了。我目前用得最顺手的几个组合多个cron脚本共用一个文本存储跑完把状态写上去另开一个通知脚本在每天固定时间汇总当天所有任务结果推一条“日报”到手机把文本读写API当“简易消息队列”一个脚本往里面放任务描述另一个脚本取出来执行实现跨进程的解耦上线前用通知API给测试群发构建结果配合文本存储存一下构建号方便回溯哪个版本存在问题。这些组合技巧让我在没有预算、没有重型基建的情况下也把日常自动化搞得井井有条。工具的价值不在于它自己多厉害而在于你能把它接进多少流程里。最后再分享一个小技巧选免费API时不要只看功能先看“退出成本”。如果有一天免费额度没了或者服务稳定下降你能否快速迁移到另一个API我建议把API调用都封装在统一的模块后面不要直接散落在业务代码里。这样切换服务商时只改动一个文件而不是全局搜替换。我做这个工具合集时最大的收获就是把“以后可能换服务商”当作默认前提来设计事实证明这个决定帮我在迁移时省了太多事。