【结论】混合内容这事儿，光靠 head 里那句 meta 和一条 SQL 替换是治不了根的，得按「定位 → 分类型处理 → 兜底 + 持续监控」三步走，主动权才在自己手里。

【展开】定位这块，控制台和源码搜 http:// 只能抓到静态写死的，动态注入的抓不到。建议直接拿 Screaming Frog 或 why-no-padlock 那类工具爬一遍全站，它会列出每一条 mixed content 的完整 URL 和行为类型。这里有个关键区分：图片、音视频属于「被动混合内容」，浏览器只警告；script、iframe、XMLHttpRequest、CSS 这类是「主动混合内容」，浏览器直接拦截不给执行，页面功能会莫名其妙挂掉，所以后者的优先级要排前面。

数据库替换有个大坑必须提——WordPress 的 options 和 postmeta 里存的是序列化数据，字符串前面写着长度前缀。你直接 UPDATE wp_options SET option_value = REPLACE(...) 把 http 换成 https，长度变了前缀没变，反序列化直接失败，轻则设置项丢失，重则整站白屏。老老实实用 wp search-replace 命令或者 Better Search Replace 插件，它们会自己处理序列化。

兜底推荐用响应头下发 Content-Security-Policy: upgrade-insecure-requests，比 meta 标签优先级高、覆盖面广。上线前先用 Content-Security-Policy-Report-Only 跑几天，收集 report 看哪些资源会被升级，确认没影响再转正式。

【最后】如果替换完还有零星资源 404，大概率是对面服务器压根不支持 HTTPS，这种别硬升级，下载到本地或换图床才是正解，硬上只会从「不安全」变成「裂图」。