靠谱的手机端user-agent需匹配平台、系统、浏览器版本的真实组合逻辑，并配套sec-ch-ua-mobile等字段；仅拼凑或轮换ua无效，应固定1–2个真实组合并确保全指纹一致。
怎么写一个靠谱的手机端 User-Agent 字符串
直接抄网上搜到的 UA 字符串，大概率被反爬识别为无效设备。真实手机 UA 的关键不是“长得像”，而是要匹配对应平台、浏览器、系统版本的组合逻辑。
比如 iOS 17.5 的 Safari 和 Android 14 的 Chrome，User-Agent 结构完全不同，硬套会触发风控。主流平台 UA 都有固定模式，不能靠拼凑。
- iOS + Safari：以
Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X)开头，必须带Version/17.5 Mobile/21F79 Safari/604.1这类精确版本字段 - Android + Chrome：以
Mozilla/5.0 (Linux; Android 14; SM-S918B)开头，后面得接AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.6422.165 Mobile Safari/537.36 - 千万别用 “iPhone15,3” 这种旧机型配 iOS 17+，系统和硬件代际不匹配会被秒判模拟器
requests 里设置 UA 的常见翻车点
很多人只改 headers 里的 User-Agent，但漏掉其他配套字段，导致请求被当成“裸 UA”拦截。
手机端请求通常还依赖 Accept、Accept-Language、Sec-Ch-Ua-Mobile 等字段协同验证。缺一两个，服务端可能返回 PC 页面或 403。
-
Sec-Ch-Ua-Mobile必须设为?1（注意问号），Chrome 系 UA 缺这个字段基本白搭 -
Accept-Language建议用zh-CN,zh;q=0.9，别写成en-US,en;q=0.9—— 中文站点看到英文 UA 会怀疑 - 别在 headers 里留空行或多余空格，
requests不报错但某些 CDN 会直接拒收
用 fake_useragent 库的风险在哪
它默认返回的 UA 大多是桌面端，且长期没更新，iOS 17、Android 14、Chrome 125+ 的 UA 根本不在库里。强行调用 fake_useragent.UserAgent().safari 返回的可能是 iOS 12 的 UA。
更麻烦的是，它返回的 UA 没有配套的 Sec-Ch-Ua- 系列字段，单独塞进 headers 里等于只交了半张身份证。
- 如果真要用，必须手动覆盖：
ua = 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_5...'，别信.random - 库生成的 UA 里常含
Edg/或OPR/，这些小众浏览器在移动端占比极低，容易被标记异常 - 它不区分移动/桌面上下文，
.chrome返回的永远是桌面版，根本不是你要的“安卓 Chrome 移动版”
抓取时 UA 要不要动态轮换
单次请求用固定 UA 完全够用；轮换只在高频采集（比如每秒 2+ 请求）时才有意义，否则反而增加指纹特征。
真正该轮换的是整个请求指纹：UA + Sec-Ch-Ua + 屏幕宽度 + Accept-Encoding 组合变化。只换 UA 是掩耳盗铃。
- 日常调试或低频采集，选 1–2 个真实组合（如 iPhone 14 + iOS 17.5 + Safari，小米 13 + Android 14 + Chrome）反复用即可
- 轮换频率别超过 10 次/分钟，太快会被当 bot；每次换完记得清空
session.cookies，避免 UA 和 cookie 设备信息对不上 - 有些网站校验
UA和Referer是否匹配移动端地址（比如 Referer 是 m.example.com 却发来 PC UA），这种细节比轮换更重要
UA 只是设备指纹的第一层，真正卡人的往往是后续的 JS 环境检测、字体列表、Canvas 指纹这些。把 UA 写对只是进门交了门票，里面还有好几道安检。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
