我从不同的开发人员那里看到了相当多的“特定于项目的扩展”，但从未见过“ user_”前缀，即使 documenatation指示使用它：
特定于项目的扩展名（通常不可用或不可共享）： 选择您喜欢的任何名称，并在名称前加上“ user _”（这是唯一 允许使用以“ u”开头的密钥）。此前缀表示 扩展是本地的，不是来自中央TYPO3 扩展存储库或曾经打算共享。大概这个 是您在某些特殊情况下所做的“临时”扩展。
但是，如果我的看法具有代表性，则开发人员倾向于使用“ client_usecase”或仅使用“ usecase”。有人告诉我，“ user_”不必要地扩展了诸如数据库表名之类的内容，并且扩展名的命名空间（供应商名/扩展名）比扩展名更重要，文档的这一部分或多或少是过去的遗迹。
我担心的是，这样的扩展密钥可能与其他扩展名冲突。 e。扩展管理器可能会尝试下载翻译并建议下载更新，可能会出现相关性问题，或者TYPO3托管人可能会安装安全补丁等。我个人在user_site扩展（项目特定的TS和模板）中使用了此前缀， f。项目并期望核心条件。 e。扩展管理器会跳过此扩展的所有翻译更新，但我什么也找不到。也许我应该建议（forge）在版本和翻译更新中排除此类扩展，并在Extension-Manager-list中将其突出显示为“特定于项目”。
我认为只有两种选择：注册扩展密钥或使用“ user_”前缀，但这似乎已经过时，或者至少通常被忽略。
使用这样的前缀是否仍然有好处，这是走的路，还是将来将来扩展密钥注册可能会被诸如卖方名称TER注册之类的东西取代？
答案 0 :(得分：2)
文档始终是一个建议-而且（几乎？）没有人使用扩展名以user_开头的密钥。
建议避免出现您所描述的冲突。但是使用程序员，公司或客户的前缀（如供应商名称）避免了冲突。
在过去，不仅表以扩展名作为前缀，而且其他表也带有其他字段。特别是如果您使用kickstarter / extensionbuilder。
今天，我们使用命名空间来避免与类名冲突，但是仍然可以与扩展名冲突，因为如果扩展名安装在typo3conf/ext/之后，则任何供应商名称都不会计算在内。
该文件夹可能可以重命名，但是在具有相同名称的表中具有相同类型的记录（具有不同的字段）可能会破坏系统。
示例：请勿尝试为名为news ;-)的新闻引入自己的扩展名
另一方面，您可能会获得具有相同信息但名称不同的字段：
latitude/longitude，lat/long，lat/lon。
从不同扩展使用不同数据表示形式命名为相同的字段呢？ time为string，unixtimestamp，time，...
结论：您无法避免所有冲突，并且通过一些明智的假设来意识到可能的问题可能有助于避免冲突。
扩展的自动更新只能在composer-install中进行，但此处的供应商名称很重要。 在没有作曲家的安装中，您可能会从TER获得扩展，其中扩展密钥与自己的扩展相同，但应该知道自己的（本地）扩展在TER中是否具有较新的版本。尤其是如果扩展名带有作者，公司或客户的前缀。
请注意，扩展不仅在TER中可用。使用composer和packagist扩展程序可以存储在任何地方。