Safari的ITP机制限制第三方Cookie、压缩第一方Cookie有效期至7天、隔离localStorage/sessionStorage、干预Web API行为并阻断跟踪脚本。开发者需通过requestStorageAccess、短期token、postMessage、fetch替代sendBeacon及动态脚本注入等技术应对。
Safari的智能防跟踪（ITP）机制会限制第三方Cookie的使用，并对网站的跟踪行为进行干预，可能导致用户身份识别失效、跨站数据同步异常或广告归因丢失。以下是ITP影响网站的关键机制及开发者需掌握的技术细节：
一、ITP对第三方Cookie的限制
ITP自2017年起逐步禁用第三方上下文中的Cookie，即当网页通过iframe嵌入或重定向跳转至其他域名时，Safari默认阻止写入和读取该第三方域名的Cookie。此限制旨在切断跨站跟踪链路。
1、检查当前页面是否处于第三方上下文中：调用document.hasStorageAccess()判断是否已获得存储权限。
2、请求存储访问权限：在用户交互事件（如点击）中执行document.requestStorageAccess()，触发权限提示。
3、监听storage access状态变更：通过document.addEventListener('webkitstorageaccessrestored', callback)捕获授权成功事件。
二、ITP对第一方Cookie的时效性削减
ITP将第一方Cookie的生命周期压缩为7天，若用户未在7天内再次主动访问该站点，则相关Cookie会被自动清除。该策略针对“静默过期”行为，防止长期隐蔽跟踪。
1、避免依赖长期有效的第一方Cookie存储用户标识：改用服务端生成短期token并配合localStorage+Service Worker缓存策略。
2、检测Cookie是否已被清除：在页面加载时读取关键Cookie值，若为空则触发重新登录或标识重建流程。
3、使用document.cookie设置时添加expires参数，但需注意该参数在ITP下仅作为参考，实际过期由ITP策略强制执行。
三、ITP对localStorage和sessionStorage的分区隔离
ITP将localStorage和sessionStorage按顶级网站（top-level domain）划分存储空间，同一域名下的不同子域（如a.example.com与b.example.com）无法共享这些API的数据，即使它们属于同一主域。
1、确认当前window.location.origin是否与预期存储域一致：避免在iframe中误用父页面域的localStorage键名。
2、使用postMessage配合同源窗口通信，在可信子域间传递必要状态，而非直接读写对方localStorage。
3、对关键状态做冗余存储：例如同时写入indexedDB与localStorage，并在读取失败时降级使用indexedDB内容。
四、ITP对Web API行为的隐式干预
ITP不仅影响Cookie和Storage，还限制navigator.sendBeacon、fetch with keepalive、以及部分Performance API的可用性，尤其在页面卸载阶段或跨域请求中，导致分析数据丢失或埋点失败。
1、替换sendBeacon为带超时控制的fetch调用：使用AbortController设定500ms超时，并在visibilitychange为hidden时立即触发。
2、在beforeunload事件中暂停异步操作：改用pagehide事件，检查document.visibilityState === 'hidden'后再发起关键上报。
3、避免在跨域iframe中调用performance.getEntriesByType('navigation')：该API在ITP启用时返回空数组，应改用window.performance.timing兼容路径。
五、ITP对广告与分析脚本的运行时阻断
ITP识别并拦截被标记为“跟踪器”的脚本资源，包括已知CDN路径、特定UA特征、或包含track/analytic/ad等关键字的URL，且不提供明确错误提示，仅表现为脚本加载失败或全局变量未定义。
1、检查script元素的onerror事件是否触发：为所有第三方分析脚本绑定onerror回调，记录加载失败情况。
2、验证关键对象是否存在：如typeof ga === 'undefined'或!window['dataLayer']，触发备用埋点逻辑。
3、采用动态script注入而非硬编码src：在用户交互后延迟加载分析脚本，并设置nonce属性以绕过部分CSP与ITP联合拦截。
