看起来 PluginStore 对我来说是实现 记住 Slack 线程 ID 以用于线程化回复 的最简单方式——但我注意到在 discourse-chat-integration 中，对它的所有使用都是孤立的；实际上没有任何东西使用查找到的值。
这是否意味着它已被弃用，还是仅仅因为正在通过其他方式实现？
我每个主题最多只存储一个值，因此考虑到所有因素，这似乎基数相对较低。这对 PluginStore 来说是合理的吗？
如果您每个主题最多存储一个值，那么使用主题自定义字段可能更适合此用例。
PluginStore 是一个简单的键值（KV）存储，适用于数据基数过高、不适合现有自定义字段表的插件场景。近年来，我们正将插件迁移到其专属表中，以在必要时提高数据可靠性，就像我们对投票插件所做的那样。如果您的用例适用，您仍然可以使用它。
谢谢，听起来我应该这么做。因为我是新手，不知能否请您提供一个插件中的主题自定义字段示例供我学习，以免打扰到您？
我想这为我指明了正确的方向，非常感谢！
给下一位刚接触并找到此内容的新手：作为一个对 Ruby on Rails 完全陌生的人，我犯过以下一些错误：
- 我以为
isolate_namespace是应该照搬的模式，却没意识到它所指代的命名空间是_路由_命名空间，与数据库无关。这给我带来了麻烦。 - 设置自定义字段并不会自动保存。你可以保存该字段所属的对象（例如
topic.save!），或者仅保存自定义字段（例如topic.save_custom_fields）。
是的，HasCustomFields 混入具有一些优势，例如 save_custom_fields、自动类型转换等。
长远来看，我们可能会移除插件商店和自定义字段，转而采用一个更加受限和受控的系统，因为它们带来的麻烦多于帮助。
目前我们使用自定义字段的唯一必要场景是：向序列化器标记帖子中存在“特殊”信息；或者在极少数情况下，当您需要对系统中 50% 的帖子进行装饰时，也会将数据存放于此。
自定义字段过于灵活，且存在大量并发问题。
添加丰富数据的最佳方式是让插件创建并拥有其所需的表。这应是您首先采取的步骤。如果您因 N+1 查询等问题而陷入困境，再考虑使用自定义字段来规避这些问题。
哇，这不会破坏现有插件生态的大部分吗？
我对 discourse-chat-integration 的贡献（以支持线程，见主题帖）是根据在这里获得的建议使用自定义字段的。
你通常如何为插件创建模型和迁移？你是使用 Rails 的主生成器，然后将它们复制到插件文件夹吗？我自己创建了一个模型和迁移生成器，可以为插件添加特定前缀。https://github.com/spirobel/discourse/tree/plugin_model_and_migrations 也许这对其他人也有用。
我建议参考 discourse-policy 和 polls 插件，了解我们进行迁移的示例。这就是您应该遵循的模式。
这一变更将逐步实施，我们将提供指导。目前过度依赖插件商店和自定义字段的系统已导致无数常规的每周问题。
我查看了投票插件，并以此为基础为插件创建了一个模型生成器，同时也创建了这个迁移生成器：
如果我的理解正确，插件商店最初被创建的原因之一是担心如果插件自行创建表，表名可能会发生冲突。我创建的这些生成器会在模型和迁移的名称前加上插件名称作为前缀。我主要创建这些生成器是因为迁移文件需要在前面加上日期编号，以确保可预测的顺序。这就是我不想手动创建它们的原因。
虽然理论上冲突是个问题，但它并不是主要的推动力。真正的推动力在于，当时对于如何运行迁移（migrations）尚不明确，而我们希望找到一个摩擦成本极低的方案。如今，在插件中创建迁移已变得非常简单，只需在迁移文件夹中创建一个文件即可。
不过，通过帖子自定义字段（post custom fields）仍然可能发生冲突。