Vue3 SPA部署Firebase后隐私页Chrome不渲染求助

问题详情 #

基于Vue3开发的单页应用，本地通过npm run serve在Firefox和Chrome中测试均正常，但部署到Firebase Hosting后，仅展示隐私、数据管理信息的页面出现异常：

• Firefox中页面显示正常
• Chrome中仅短暂渲染顶部图片后，页面主体内容全部消失，仅保留Header和Footer
  该页面为Vue Router渲染的视图组件，位于Header与Footer之间。

页面代码 #

<template>
  <div class="gdpr-outer">
    <h1>那么你关心隐私问题……</h1>
    <img class="ninjaimg" src="@/assets/ninjaimg.webp" alt="隐身人" />
    <h2>我得说你做得对！</h2>
    <p style="text-align: center">
      随便点击网站却不阅读相关内容会惹来不少麻烦……所以我们把事情说清楚！
    </p>
    <h1>Cookies说明</h1>
    <p>
      Cookies是浏览器在你浏览期间保存的小型文本文件。按下F12，点击“Application”/“应用程序”，在“Storage”部分就能找到所有Cookies，数量可能真的很多！你正在访问的网站使用这些Cookies来提供互动化、个性化的体验：比如当你登录某个网站时，浏览器会保存登录信息，这样网站就能识别你已登录，无需每次进出都重新登录。
    </p>
    <p>
      一切都很美好，直到广告商们说：“嘿！我们为什么不利用Cookies追踪用户感兴趣的内容，然后把这些信息卖给相关企业呢？”可拉倒吧：上次我搜索了橡胶鸭，结果看到的广告多得让我差点变成养鸭户……
    </p>
    <p>
      那该怎么办？我选择不使用这类Cookies。法规要求我必须使用一个单独的Cookies来追踪GDPR同意情况，还有一个用于管理夜间模式（不过这个功能真的很方便，对吧？）。仅此而已：如果你发现其他Cookies，那都不是我设置的！
    </p>
    <p>
      <b>
        我在此明确说明：本网站不使用用于营销或广告追踪的Cookies，任何第三方从未拥有、现在没有也不会拥有访问本网站管理的任何Cookies的权限（主要是因为根本没有其他Cookies……）。
      </b>
    </p>
    <h1>请求追踪说明</h1>
    <p>
      本网站本质上是一个博客，那么猜猜博客管理者最希望什么？没错，希望有人阅读。除此之外，如果能了解读者对哪些内容更感兴趣就更好了：偏好的阅读时间、浏览博客使用的设备以及最受欢迎的内容，这些都是博客管理者的重要数据。因此，本网站会收集一些基础的浏览数据，如下所示：
    </p>
    <ul>
      <li>连接日期和时间</li>
      <li>远程地址（remoteAddress）</li>
      <li>请求页面（requestURI）</li>
      <li>来源页（header["Referer"]）</li>
      <li>使用的平台（header["Sec-Ch-Ua-Platform"]）</li>
      <li>移动设备（header["Sec-Ch-Ua-Mobile"]）</li>
      <li>使用的浏览器（User Agent）（header["User-Agent"]）</li>
    </ul>
    <p>
      这些数据会在你每次浏览博客页面或文章时被收集。每个页面底部还有一个小横幅（因为它很丑所以做得很小，但没办法）来提醒你。这些数据仅用于统计目的。此外，我无法通过这些数据了解你的身份、姓名、住址或任何与你直接或间接相关的信息。你每天访问的几乎所有网站都会收集这些信息，通常还用于商业目的。本网站收集的数据仅用于统计目的（毕竟我总得管理这个博客对吧？）。
    </p>
    <p>
      关于远程地址（IP）的小说明：追踪这个数据能让我大致了解你浏览博客的地理区域。注意：<b>地理区域</b>，不是具体地址、地区、省、市和街道。无论你使用静态还是动态IP，我都无法从IP地址中获取这些详细信息。实际上，我通过这个数据只能判断你更靠近墨西哥还是中国。我特意说明这一点，是因为很多法规对于动态IP是否属于个人数据存在分歧。从技术上讲，它不应该属于个人数据，因为无法通过IP地址追踪到个人，除非有办法将该地址与连接的户主关联起来。但我不是电信公司：我做不到，也没兴趣这么做。
    </p>
    <p>
      <b>
        因此总结：我收集这些数据并非用于商业目的，仅用于博客的统计和管理目的。任何第三方都无权访问这些数据，你随时可以要求删除、修改或查看这些数据。
      </b>
    </p>
    <h1>Google reCaptcha说明</h1>
    <p>
      本网站使用Google提供的reCaptcha系统来追踪网站上的潜在机器人活动：仅在文章页面启用。实际上，网站会识别、分析并为你访问的博客文章页面上的活动打分。如果用户不是人类（即机器人或某种自动请求系统），reCaptcha系统会识别出来并阻止其发表评论。这不是因为我想知道你是不是人类，而是因为如果制作合适的机器人，每秒可以发表数千条评论，让我可怜的服务器不堪重负。
    </p>
    <p>
      如果你访问一篇文章，查看右下角，会看到一个带三个环形箭头的小方块，这表示reCaptcha系统已启用并正常工作。如果你想了解更多reCaptcha的工作原理，我建议你点击该图标并阅读隐私说明。或者，你可以直接访问Google的专用页面获取有用信息。
    </p>
    <h1>我的数据在哪里？</h1>
    <p>
      正如一位老智者所说：“避免麻烦的最好方法就是不惹麻烦”。数据安全至关重要，而数据安全管理也变得日益复杂。就我而言，我既没有相关基础设施，也没有专业知识来确保数据的绝对安全。实际上，朋友们，我不能只是把数据保存在家里的硬盘上，锁在抽屉里然后说“好了，待在那里别动”。这行不通。<br />出于同样的原因，为了避免对本网站可能的（尽管可能性很小）网络攻击，本网站实际托管在一家虚拟服务器托管公司管理的虚拟服务器上，这家公司在管理博客传输的所有数据的安全性方面肯定比我专业得多。
    </p>
    <p>
      根据法律规定，我必须告知你，收集的浏览数据并不在我手中（不过话说回来，现在没有什么东西是真正在谁手里的，想想云盘、Dropbox之类的……）。那么这是否意味着这家公司<b>可以查看我的数据</b>？答案是：<b>不行</b>。即使服务器由他们维护，服务器管理者（也就是我）仍然是唯一有权访问数据的人。
    </p>
    <h1>谁管理我的数据？</h1>
    <p>
      数据管理者就是我（谁能想到呢？）。以下是相关支持请求的详细联系方式：
    </p>
    <p>
      Nicola Moro<br />邮箱1: nicola.moro@n-bit.it <br />邮箱2: nicola.moro@live.it
    </p>
    <p>
      如有任何需求或情况，请随时联系我，最后祝你浏览愉快！
    </p>
    <p style="font-size: 10px">
      <i>
        封面图：Walk Off The Earth在Giphy上的Ninja Spy GIF
      </i>
    </p>
  </div>
</template>

<script>
export default {
  mounted() {
    console.log("Emitting close event for the banner");
    this.$emit("close");
  },
  unmounted() {
    if (!document.cookie.includes("gdpr=true")) {
      console.log("Emitting show event for the banner");
      this.$emit("showBanner");
    }
  },
};
</script>

<style scoped>
p {
  width: 70%;
}
ul {
  list-style: none;
  margin: none;
}
.gdpr-outer {
  margin-top: var(--space-uunit);
  display: flex;
  flex-direction: column;
  gap: var(--space-uunit);
  align-items: center;
}
.ninjaimg {
  border: 5px solid var(--color-main);
  width: 25%;
  border-radius: 32px;
}
</style>

排查方向 #

• Chrome控制台错误排查：打开Chrome开发者工具（F12），查看Console面板是否有JS执行错误、资源加载失败提示；切换到Elements面板，检查gdpr-outer元素的样式是否被意外覆盖或隐藏，尤其注意自定义CSS变量--space-uunit、--color-main是否在生产环境中正确定义。
• 生产构建资源校验：执行npm run build后，检查dist目录下是否存在ninjaimg.webp，确认资源路径与代码中引用完全一致（Firebase Hosting对路径大小写敏感）。
• Vue Router与Firebase配置检查：若使用history模式，确认firebase.json中的重写规则是否正确配置，避免路由跳转后页面资源加载异常。
• 样式冲突排查：临时移除页面样式的scoped属性，测试是否存在全局样式与页面样式冲突导致内容隐藏的情况。
• 生命周期事件影响验证：检查父组件中close和showBanner事件的处理逻辑，确认是否存在误操作隐藏当前页面容器的代码。
• Chrome缓存清理：按Ctrl+Shift+R强制刷新页面，清除浏览器缓存后重新加载，排除旧缓存资源导致的渲染问题。
• Firebase缓存策略检查：查看Firebase Hosting的缓存规则，确认该页面相关资源是否被设置了过强的缓存策略，导致资源未正确更新。

内容的提问来源于stack exchange，提问作者NicolaM94