使用"user_"前缀命名TYPO3扩展键是否仍存在益处？

Great question—this is a super common point of confusion in the TYPO3 community, especially since the shift to Composer-based workflows. Let’s break this down clearly:

1. The original intent of the user_ prefix #

First, let’s recap the official guidance:

项目专属扩展（不具备通用或共享性）：可任意命名并添加"user_"前缀（这是唯一允许以"u"开头的键名用法），该前缀表明此扩展为本地扩展，并非来自TYPO3官方扩展仓库（TER），也不打算对外共享，通常是为特定场景开发的临时扩展。

This rule dates back to the pre-Composer era, when TYPO3 relied heavily on the Extension Manager to pull extensions from TER. The user_ prefix was a clear signal to the core system: "This is local—don’t check TER for updates, translations, or dependencies."

2. Why most developers skip it now #

You’ve already nailed the main reasons the community has moved away from it:

• Unnecessary length bloat: The prefix adds redundant characters to database table names (e.g., tx_usermyextension_domain_model_content instead of tx_clientmyproject_domain_model_content), which can be tedious to work with.
• Composer namespaces are a better solution: Modern TYPO3 uses Composer, where extensions are identified by vendor/extension-name (e.g., myagency/client-website). The vendor name acts as a natural, unique namespace, preventing conflicts far more effectively than a generic user_ prefix.
• Legacy rule perception: Many developers see this as an outdated holdover from TYPO3’s early days, not a relevant guideline for modern, Composer-driven workflows.

3. The real risks of skipping the prefix #

Your concerns are valid—there are tangible downsides to ignoring the rule:

• Update/translation conflicts: If your extension name matches one hosted on TER, the Extension Manager might mistakenly try to pull updates or translations for it, leading to confusing error messages or unexpected behavior.
• Dependency or patch interference: While rare, if a security patch is released for a TER extension with the same name, there’s a small chance it could clash with your local extension (though Composer’s namespaceing mitigates this mostly).
• Team confusion: New team members might mistake your local extension for a public one, wasting time searching TER for documentation or updates.

4. Is the user_ prefix still worth using? #

It depends on your workflow:

• If you’re on a pre-Composer TYPO3 version: Absolutely. The prefix is still the most reliable way to tell the core system to treat the extension as local.
• If you want explicit visual clarity: The prefix is a quick, universal signal that an extension is project-specific and never going to be shared. For teams with mixed experience levels, this can reduce confusion.
• If you’re using Composer: Probably not necessary. Using a custom vendor name (like your agency or client’s name) is a more modern, scalable way to avoid conflicts. For example, clientx/site-config is more descriptive than user_site and just as safe.

5. Your proposal for improving the system #

Your idea to suggest on Forge that TYPO3 add better support for project-specific extensions is spot-on. The core system should ideally recognize local extensions (regardless of prefix) and mark them as "Project-specific" in the Extension Manager, skipping update/translation checks. This would align the docs with real-world practices, and the community would likely support this improvement.

Final takeaways #

• If you’re happy using user_ and it’s working for your team: Keep doing it—there’s no harm in sticking with a rule that still serves its purpose.
• If you’re moving to Composer: Switch to a vendor-prefixed naming scheme. It’s cleaner, more scalable, and avoids the table name bloat issue.
• Most importantly: Standardize on one approach within your team. Consistency is key to avoiding confusion down the line.

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