真正有效的方案是用UA检测+运行时加class，而非依赖CSS媒体查询；prefers-reduced-data和prefers-color-scheme仅反映系统偏好，与分享动作无直接关联，且在内嵌WebView中支持不一。
分享链接时样式错乱，怎么用prefers-reduced-data或prefers-color-scheme区分？
不能靠“分享时自动加class”这种幻想——微信、钉钉、飞书等内嵌WebView根本不执行你的JS，也不保留你页面的运行时状态。真正能用的，只有CSS媒体查询里那些浏览器原生支持、且在内嵌环境里依然生效的特性。
实际有效的是prefers-reduced-data（部分安卓微信WebView已支持）和prefers-color-scheme（多数内嵌环境会继承宿主系统主题）。但注意：prefers-reduced-data: reduce不是“分享模式开关”，它只反映用户是否开启了省流量模式，和分享动作无直接关系。
- 别写
@media (prefers-reduced-data: reduce) { .ad-banner { display: none; } }来“适配分享”——这只会让开省流的用户看不到广告，和分享无关 - 如果目标是微信内隐藏某些元素，唯一稳定方式是检测
navigator.userAgent含MicroMessenger后动态加class，再用CSS控制；纯CSS做不到 -
prefers-color-scheme在iOS微信里基本可用，在安卓微信里部分版本失效，需实测
用iframe内嵌时，父页面样式穿透不了，怎么隔离又可控？
父页面无法用iframe外的CSS影响内部样式，这是同源策略+Shadow DOM边界共同决定的。想控制内嵌页表现，只有三个可行路径：改内嵌页本身、用postMessage通知其切换主题class、或者服务端根据Referer或User-Agent返回不同HTML。
- 如果内嵌页和父页同域，可在父页中通过
iframe.contentDocument注入style标签，但必须等load事件后操作，且Chrome 80+对跨iframe脚本有更严限制 - 异域场景下，
postMessage是最通用方案：父页发{ theme: 'embed-read-only' }，子页监听并切换document.body.dataset.theme，再用[data-theme="embed-read-only"] .edit-btn { display: none; } - 避免用
!important强行覆盖——内嵌页若用了CSS-in-JS或Shadow DOM，这类覆盖大概率失败
微信/飞书内嵌WebView里print样式失效，怎么强制用阅读模式？
所谓“阅读模式”本质是移除干扰元素、调大字号、换行距、禁用背景图——但微信内置浏览器不触发@media print，也不响应window.matchMedia('print')。真要模拟，得靠运行时检测环境 + 手动激活类名。
立即学习“前端免费学习笔记（深入）”；
- 检测
/(MicroMessenger|Lark|DingTalk)/.test(navigator.userAgent)，命中后立即给<body>加class="in-app-readonly" - CSS里写
.in-app-readonly { --font-size-base: 18px; --line-height: 1.7; }，所有文本用font-size: var(--font-size-base)，比硬写16px更易维护 - 背景图一律用
background-image: none覆盖，别依赖prefers-reduced-data——它在微信里多数不生效
为什么@media screen and (width < 480px)在分享卡片预览里不生效？
分享卡片（如微信“转发给朋友”弹窗里的缩略图）压根不是真实页面渲染，而是服务端截图或静态快照，连JS都不执行，更别说媒体查询。你看到的“小屏样式”，其实是微信用固定宽度（通常是320px或375px）截的图，但截图时用的DOM状态是你页面初始加载那一刻的，不会重新计算媒体查询。
- 分享卡片样式不可控，唯一能干预的是
<meta name="viewport">设置，确保截图时布局不溢出 - 别指望用
resize事件或matchMedia监听去“修复分享图”——它根本没运行JS - 如果需要定制分享图，必须走OpenGraph协议：
<meta property="og:image" content="https://xxx/share-card-375x200.png">，这是唯一可靠方式
