这个答案主要是我自己在未来使用的参考，因为大多数答案都没有提供一个成熟的解决方案。下面就是:

第一次运行:

compinit

如果以上都不起作用，请使用compaudit

对于打印的每个路径，运行以下命令:

sudo chown $(whoami) PATH_HERE

sudo chmod -R 755 PATH_HERE

简单的例子，假设运行compinit后打印的路径之一是“/usr/local/share/zsh”。然后:

sudo chown $(whoami) /usr/local/share/zsh

sudo chmod -R 755 /usr/local/share/zsh

我的建议是运行compaudit，然后修复由审计发现的目录的权限。 确保识别的目录没有组或其他的写权限。

当我sudo -i启动根shell时，我得到了相同的警告，@chakrit的解决方案对我不起作用。

但我发现-u开关的compinit工作，例如在你的.zshrc/zshenv或你调用compinit的地方

compinit -u

注意:不建议用于生产系统

参见http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Initialization

大多数答案都提供了解决方案，但没有提到为什么会出现这种警告。以下是ZSH公司的一段摘录:

For security reasons compinit also checks if the completion system would use files not owned by root or by the current user, or files in directories that are world- or group-writable or that are not owned by root or by the current user. If such files or directories are found, compinit will ask if the completion system should really be used. To avoid these tests and make all files found be used without asking, use the option -u, and to make compinit silently ignore all insecure files and directories use the option -i. This security check is skipped entirely when the -C option is given.

因此，解决方案意味着解决以下一个(或所有)问题:

将当前用户设置为所有目录/子目录/文件的所有者，原因如下: compaudit | xargs chown -R "$(whoami)" 删除组/others文件的写权限，原因如下: Compaudit | xargs chmod go-w

另一种方法是使用跳过这些检查

compinit -u

但我并不建议这样做，因为把问题藏在地毯下只能在短期内解决问题。

这是我在https://github.com/zsh-users/zsh-completions/issues/433#issuecomment-600582607上唯一有用的东西。感谢https://github.com/malaquiasdev !

  $ cd /usr/local/share/
  $ sudo chmod -R 755 zsh
  $ sudo chown -R root:staff zsh

在我的mac OS Catalina上运行这个命令是有效的:

Compaudit | xargs chmod g-w,o-w