PrestaShop 的全局配置表使得模块的卸载程序很容易擦除完全不相关的扩展程序的设置。仅需调用一次 Configuration::deleteByName('width')，就可能抹除另一家店铺的自定义宽度值，让商家感到困惑，而引起问题的模块看起来却似乎并无大碍。
为什么共享配置表至关重要
PrestaShop 将每个模块的设置存储在一个仅包含键（key）和值（value）的表中。该表没有记录哪一个模块创建了某行数据的列，也没有强制执行任何命名规范。因此，如果两个模块碰巧使用了相同的键——例如 “width” 或 “API_DATE_FROM”—它们将读取并写入同一行数据库记录。最后一次写入的操作会生效，而任何随后的删除操作都会同时删除双方的记录。
当卸载代码变成数据擦除工具时
一个典型的卸载方法如下所示：
public function uninstall()
{
return Configuration::deleteByName('width');
}
其本意是清理模块自身的配置，但由于键没有使用命名空间，该语句会删除任何名为 “width” 的行。系统不会记录警告，也不会抛出异常；该行数据就这么消失了。商家的其他模块会悄无声息地丢失其设置，并可能开始出现异常行为。
在版本升级期间，这个问题尤其容易发生。从 1.0 版本迁移到 2.0 版本的开发人员可能会开始将值保存在带有前缀的键下，例如 MY_MODULE_WIDTH。为了“清理”旧的、没有前缀的条目，他们会在卸载程序中添加一个删除调用，认为自己只是在移除旧数据。而实际上，他们也删除了其他任何存储在相同通用键下的扩展程序数据。
审计发现了什么
对 57 个公开模块仓库的审计揭示了一个反复出现的模式：
- 许多模块使用诸如 “width”、“height” 或 “API_DATE_FROM” 之类的通用键，而没有使用源自模块名称的前缀。
- 若干卸载方法包含针对这些通用键的
Configuration::deleteByName调用。 - 该问题并不局限于单个开发人员或特定类型的模块；共享表的设计使其成为一种系统性风险。
审计并未发现任何能够提醒店主另一个模块配置已被移除的日志或错误消息。唯一的症状是设置突然丢失，而商家可能会将其归因于缓存问题或其自身代码中的错误。
模块开发者的更安全实践
- 为每个键设置命名空间 – 在每个配置键前加上模块的技术名称（例如
my_module_width）。这样可以在不依赖单独的所有权列的情况下创建唯一标识符。 - 避免删除旧的、无前缀的键 – 在表中保留少量过时的行几乎不占用存储空间，且能消除误伤风险。
- 删除前验证所有权 – 如果确实需要删除，请先检查该键的值是否由您自己的代码设置（例如，存储一个只有您的模块才知道的标记值）。
- 审计卸载方法 – 在代码库中搜索
deleteByName调用。应检查每一次调用，以确认该键已使用了唯一的命名空间。 - 记录命名规范 – 在模块的 README 中包含简短的指南，以便未来的贡献者了解带前缀键的重要性。
测试是否存在意外的跨模块删除
在问题影响到正式店铺之前，一种实用的捕捉方法：
- 为配置表注入数据：注入一个属于不同模块的键（例如
other_module_setting=>test）。 - 在受控环境中运行模块的卸载程序。
- 断言在卸载完成后，注入的键仍然存在。
在模块的单元测试套件中自动化此检查，可以确保未来任何引入误用 deleteByName 调用的更改都会导致测试失败，从而促使进行审查。
店主应该注意什么
店主很少能看到内部数据库行，但他们可以察觉到症状：在禁用或卸载某个模块后，另一个扩展程序突然恢复到了默认设置。如果发生这种情况，请要求开发人员验证该模块的卸载代码是否遵循了全局配置表的规范。要求提供模块使用的所有配置键列表；任何没有清晰前缀的键都是危险信号。
核心结论
PrestaShop 的设计使得配置表成为一种共享资源，而粗心的卸载程序可能会在不留痕迹的情况下抹除其他模块的设置。通过为键（keys）实施命名空间管理、避免激进的清理操作，并添加一个能够保护外部条目的简单测试，开发者可以防止静默数据丢失，并确保商家店铺的稳定性。虽然这所投入的精力微乎其微，但设置丢失所带来的代价——客户投诉、支持工单以及声誉受损——可能会高得多。