致命错误：Uncaught ArgumentCounter错误：函数TYPO3\CMS\Core\Imaging\IconFactory的参数太少：：\uu构造（）

遵循的composer安装指南之后。我将apachevhost指向公用文件夹。一旦在浏览器中导航到index.php位置，就会出现此错误

Fatal error: Uncaught ArgumentCountError: Too few arguments to function
TYPO3\CMS\Core\Imaging\IconFactory::__construct()
0 passed in /home/user/projects/typo3/public/typo3/sysext/core/Classes/Utility/GeneralUtility.php
on line 3423
and exactly 2 expected in
/home/user/projects/typo3/public/typo3/sysext/core/Classes/Imaging/IconFactory.php:71

---

这看起来像是一个依赖注入问题。请任何人帮助我解决此错误

此问题发生在将现有项目从服务器移动到DDEV后（类似于通过vhost配置更改路径/URL）。我猜这与缓存文件中更改的路径/URL有关。我就是这样解决的：

Fatal error: Uncaught ArgumentCountError: Too few arguments to function
TYPO3\CMS\Core\Imaging\IconFactory::__construct()
0 passed in /home/user/projects/typo3/public/typo3/sysext/core/Classes/Utility/GeneralUtility.php
on line 3423
and exactly 2 expected in
/home/user/projects/typo3/public/typo3/sysext/core/Classes/Imaging/IconFactory.php:71

A） 手动删除所有缓存文件：

t3project$ rm -rf public/typo3temp/*
t3project$ rm -rf var/*

---

B） 此外，我还必须将一些自动生成的文件夹/文件的所有权更改为我的当前用户（

sudo chown-R myuser:myuser t3project/

），然后我就能够在“环境>目录状态”中使用“修复文件夹结构”工具，现在一切都恢复正常。不确定最后一步是否对您有帮助，因为这可能只与我的情况有关，即某些文件夹/文件在复制时拥有错误的所有者。

我今天也遇到了同样的问题，因为我在这段代码中超出了一个核心类并使用了

GeneralUtility:：makeInstance（IconFactory:：class）

。
修复方法是在这个类中使用DI，正如您所建议的那样。之后还要刷新所有缓存以重建DI容器

由此：

类CTypeList扩展了AbstractList { 公共函数项sprocfunc（&$params） { $fieldHelper=GeneralUtility:：makeInstance（MASK\MASK\Helper\fieldHelper:：class）； $storageRepository=GeneralUtility:：makeInstance（MASK\MASK\Domain\Repository\storageRepository:：class）； ... 为此：

类CTypeList扩展了AbstractList { 受保护的StorageRepository$StorageRepository； 受保护的FieldHelper$FieldHelper； 公共函数构造（StorageRepository$StorageRepository，FieldHelper$FieldHelper） { $this->storageRepository=$storageRepository； $this->fieldHelper=$fieldHelper； } 公共函数项sprocfunc（&$params） { $this->storageRepository->doStuff（）； $this->fieldHelper->doStuff（）； ... 供其他人日后参考： 当核心在类上使用

GeneralUtility:：makeInstance

时，这也可能发生在自己的扩展中（例如在AuthenticationServices中）。 这里的诀窍是让这些DI服务像这样公开：

（在extension\u path/Configuration/Serivces.yaml中）
服务：
_默认值：
自动连线：对
自动配置：正确
公众:错
供应商\ExtensionName\Service\FrontendOAuthService：
公众：是的

以下是它的文档：

---

我出现此错误是因为我在一个扩展名中使用了

Services.yaml

文件，但没有正确配置它

可以找到有关该文件本身的更多信息

由于该文件负责依赖项注入，一些小错误（例如名称空间中的错误）会导致上述错误

要查找错误，可以使用

Services.yaml

卸载扩展。 找到文件/扩展名后，必须检查

Classes

目录中的所有名称空间是否正确。 这意味着：

• 关于所包含的类，所有文件名都是正确的
• 文件中的所有名称空间的路径和文件名都正确
• 命名空间可以通过composer找到。因此扩展必须通过composer安装，或者必须在

  composer.json的自动加载列表中有一个条目

---

尝试了这些，但没有成功。错误消息与使用nginx 1.14.2和PHP 7.3的OP完全相同。问题是，您甚至无法输入任何类型的Typo3 web界面，即“修复文件夹结构”无法使用建议。键入3故障排除也没有帮助。是的，我知道，前端和后端都会引发错误。但在我的情况下，我可以在删除所有生成的临时文件后打开安装工具（

缓存

，

锁定

，

日志

，

会话

等）。正如我所说，步骤B）可能是可选的，但我不确定。我在两个不同的项目上测试了此解决方案两次，两次错误都是在步骤A）之后出现的。