# 嵌入资源主题
**URL:** https://meta.discourse.org/t/embed-assets-theme/371868
**Category:** Support
**Created:** [2025年六月26日 17:58 UTC](https://meta.discourse.org/t/embed-assets-theme/371868 "2025-06-26T17:58:32Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@nlambert](https://meta.discourse.org/u/nlambert)
#### Post date: [2025年六月26日 17:58 UTC](https://meta.discourse.org/t/embed-assets-theme/371868/1 "2025-06-26T17:58:32Z")
各位朋友，
我浏览了几个帖子寻找答案——并且找到了许多（下面有链接——谢谢你们！）。多亏了这些帖子，我能让大部分东西看起来符合我的要求。但仍有一个问题我没能解决。
这关系到嵌入式资源文件，特别是 `embed_HASH.css` 文件。
**看起来** 当这些资源被构建时，它们不是使用活动主题的调色板编译的。这可能是设计如此，也可能是我遗漏了什么。
我想弄清楚以下几点：
1. **`embed_[digest].css` 是否总是使用默认调色板构建？**
如果是这样，我可以接受——我知道在改进 Discourse 的主题和调色板处理方式方面有很多正在进行的工作。
2. **如果它_可以_使用自定义调色板构建，我该如何触发这种行为？**
3. **我注意到它可以根据系统的浅色或深色调色板构建** ，所以似乎有可能使用自定义调色板——但我一直无法可预测地生成浅色或深色嵌入文件。
为了测试这一点，我删除了所有主题和调色板，将所有内容恢复到默认的浅色主题，然后运行了：
```plaintext
rake assets:precompile
rake assets:precompile:build
```
……期望得到一个浅色主题的 `embed_HASH.css`。但结果似乎仍然使用了深色样式。
我对内部机制不太熟悉，所以可能遗漏了显而易见的东西。如果有人能分享一下如何让 `embed_HASH.css` 使用可预测的调色板构建，那将非常有帮助。
提前感谢！
供参考，我的 Discourse 实例运行在 Docker 中，并且是最新的。我使用了 `launcher` 脚本和独立模板。
> 相关阅读（新账号只允许 2 个链接，第 3 个是可搜索的标题）：
>
> - [How to customize appearance of discourse embeds?](https://meta.discourse.org/t/how-to-customize-appearance-of-discourse-embeds/240026)
> - [Styling of Embedded Discourse](https://meta.discourse.org/t/styling-of-embedded-discourse/31956)
> - 嵌入式评论是否也支持自动暗模式？
---
### Author:  [@nlambert](https://meta.discourse.org/u/nlambert)
#### Post date: [2025年六月27日 01:37 UTC](https://meta.discourse.org/t/embed-assets-theme/371868/2 "2025-06-27T01:37:06Z")
我找到了我问题的部分答案，并想分享我的见解：
`embed_[digest].css` 文件确实是使用活动主题的选定颜色调色板构建的。
我意识到问题出在 **非常激进的 HTTP 响应缓存** 上。
我仍然希望有人能回答：
**Discourse 在哪里缓存资源文件的 HTTP 响应？**
这不仅仅是浏览器端的缓存——它似乎也是服务器端的。
* * *
当跟踪 Rails 生产日志时，我注意到只有具有 **新、未见过的一组查询参数** 的请求才会触发新的资源渲染：
```bash
$ tail -n 50 shared/standalone/log/rails/production.log -f
Started GET "/stylesheets/embed_afe162195ad0a7185309a19d8c36036d2e53708c.css?__ws=domain.tld&foo=bif" for fd00:aaaa::f1a at 2025-06-27 01:14:38 +0000
Processing by StylesheetsController#show as CSS
Parameters: {"__ws"=>"domain.tld", "foo"=>"bif", "name"=>"embed_afe162195ad0a7185309a19d8c36036d2e53708c"}
Sent file /var/www/discourse/tmp/stylesheet-cache/embed_afe162195ad0a7185309a19d8c36036d2e53708c.css (0.2ms)
Completed 200 OK in 22ms
```
在那之后，任何后续对同一 URL 的请求（即使具有不同的查询字符串）都会返回 **相同** 的响应——即使底层主题已更改。
例如：
1. `https://domain.tld/stylesheets/embed_[digest].css?__ws=domain.tld`
2. `https://domain.tld/stylesheets/embed_[digest].css?__ws=domain.tld&foo=bar`
我只在 **第一次** 使用唯一查询时才看到更新的主题样式。所有后续具有相同参数的请求都会提供先前版本，即使在重新编译之后也是如此。
`launcher` 脚本默认为 `RAILS_ENV=production`，我保持原样。我可以在开发过程中尝试切换到 `RAILS_ENV=development` 以完全禁用缓存，但理想情况下，我想知道：
> **如何在生产环境中清除或禁用资源响应的 HTTP 级别缓存？**
如果有人对 Discourse 如何缓存这些资源响应——或如何正确使其失效——有任何见解，那将非常有帮助。
---
### Author:  [@nlambert](https://meta.discourse.org/u/nlambert)
#### Post date: [2025年六月27日 03:00 UTC](https://meta.discourse.org/t/embed-assets-theme/371868/3 "2025-06-27T03:00:20Z")
哦，天哪 😳 原来是 Nginx！
### 简而言之：
```bash
rm -rf /var/nginx/cache/*`
```
瞬间解决！
* * *
## 可选：禁用 Nginx 资源缓存
编辑此文件：
```plaintext
/etc/nginx/conf.d/discourse.conf
```
在大约第 243-246 行，注释掉缓存指令：
```c
# proxy_cache one;
# proxy_cache_key "$scheme,$host,$request_uri";
# proxy_cache_valid 200 301 302 7d;
# proxy_cache_bypass $bypass_cache;
```
然后重启 Nginx：
```bash
sv restart nginx
```
### 🎨 如果您正在更改配色方案…
仅编辑主题中的颜色设置**不会重新生成 `embed_[digest].css`**。要强制 Discourse 生成新的资源文件，请执行此操作：
```bash
rm tmp/stylesheet-cache/* # 或者，仅针对 embed，`rm tmp/stylesheet-cache/embed*`
```
### 🤔 `RAILS_ENV=development` 怎么样？
您可能认为设置 `RAILS_ENV: development` 会禁用缓存，但是：
- Discourse 使用的 `nginx.sample.conf` **默认启用** 缓存，无论环境如何
- 该缓存 **不与 `RAILS_ENV` 绑定** ，因此它无助于嵌入式资源缓存
因此，除非您计划完全重新配置 Nginx 层，否则只需 **手动清除缓存或禁用那些行** 即可。_准备好生产环境后，您可以恢复原状。_
### 🐢 `./launcher rebuild standalone` 怎么样？
当然，它有效。但是，如果您正在积极调整主题、测试嵌入和调整颜色…您会希望每次都比等待几分钟更快。
### 💬 有更好的开发设置或快速修复方法？请评论！
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [2025年七月27日 03:00 UTC](https://meta.discourse.org/t/embed-assets-theme/371868/4 "2025-07-27T03:00:33Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.