企业微信Webhook定时推送需防超时、密钥泄露、@失败、频率限流四类静默失效；必须设timeout=(3,7)、用环境变量管理密钥、@用准确账号列表、按场景选crontab或APScheduler并加限流。
能，但关键不在“怎么发”，而在“怎么不翻车”——定时任务+Webhook组合最容易在超时、密钥泄露、@失败、频率限流这四点上静默失效。
requests.post 必须带 timeout 和异常捕获
企业微信接口不是永远在线的。DNS 解析失败、网络抖动、服务端临时限流，都可能导致 requests.post 卡住几十秒甚至更久。尤其在 crontab 或 APScheduler 里，没设超时会积压僵尸进程。
必须写成这样：
try:
resp = requests.post(
url=webhook_url,
json=payload,
timeout=(3, 7) # 3秒连不上就放弃，7秒内没响应也中断
)
result = resp.json()
if result.get("errcode") != 0:
print(f"发送失败: {result.get('errmsg')}")
except requests.exceptions.RequestException as e:
print(f"网络异常: {e}")
-
timeout=(3, 7)是硬性要求，不能只写一个数字 - 别只看
resp.status_code == 200，企业微信返回 200 但errcode=40014（key 错误）或errcode=45009（每分钟超 20 条）照样算失败 - 建议加一次重试（
time.sleep(1); requests.post(...)），但别自动重试 3 次以上，避免雪崩
Webhook 地址绝不能硬编码在代码里
把 https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxx 直接写进 .py 文件，等于把群发权限贴在 GitHub 上。已有团队因此被刷屏发广告。
立即学习“Python免费学习笔记（深入）”；
正确做法是用环境变量：
Secure Python Code Sandbox
下载
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
import os
webhook_url = os.getenv("WECHAT_WEBHOOK")
if not webhook_url:
raise ValueError("WECHAT_WEBHOOK 环境变量未设置")
- 本地开发：用
.env文件 +python-dotenv自动加载，记得把.env加进.gitignore - Linux 生产环境：在
/etc/profile或 crontab 前加export WECHAT_WEBHOOK="https://..." - 云函数（如腾讯云 SCF）：在控制台配置环境变量，别写进代码包
@所有人或指定成员必须用列表格式，且账号名要准确
想在文本消息里 @ 所有人，写 "mentioned_list": "@all" 是无效的——接口会静默忽略。企业微信严格要求它是字符串列表，且大小写敏感。
正确示例：
{
"msgtype": "text",
"text": {
"content": "数据库备份已完成，请查收。",
"mentioned_list": ["@all"] // 注意：是列表，不是字符串
}
}
-
["@all"]有效，["@ALL"]或["@All"]无效 - 要 @ 某个具体人，必须填其「成员账号」（不是昵称或手机号），比如
["w123456789"]，这个要去企业微信后台「通讯录」里查 - @所有人功能在禁言群或无发送权限的成员身上不会触发提醒，别假设它一定响
定时任务选 crontab 还是 APScheduler？看你的稳定性需求
两者都能跑，但风险点完全不同：
-
crontab：稳定，跟 Python 进程解耦，但每次执行都是新进程，环境变量、Python 路径、依赖版本容易出错；日志分散，调试困难 -
APScheduler：所有逻辑在同一个进程里，日志/配置/异常统一管理，但进程挂了整个定时就停，必须配 systemd 或 supervisor 守护
简单脚本推荐 crontab，例如每天早 9 点推日报：
0 9 * * * cd /path/to/script && /usr/bin/python3 report.py >> /var/log/wechat.log 2>&1
复杂服务（比如要同时查 DB、调 API、生成图表）建议用 APScheduler + systemd，否则 cron 每次都要重连数据库、重载配置，开销大还容易漏状态。
最常被忽略的一点：企业微信机器人每分钟最多发 20 条消息，超频直接返回 errcode=45009。如果你的定时任务每 10 秒跑一次，又没做去重或节流，不到一分钟就被熔断——得自己加计数器或用 Redis 限流，不能只靠 try-except。
