Windows CMD默认使用GBK编码，而Composer和PHP采用UTF-8，导致中文乱码。解决方法包括：临时使用chcp 65001切换为UTF-8编码，或长期改用Git Bash、Windows Terminal、WSL等支持UTF-8的现代终端，从根本上避免编码冲突，提升开发体验。
Composer在Windows命令行（CMD）下遇到字符编码问题，核心原因在于CMD默认的GBK编码与Composer及其依赖的PHP环境普遍使用的UTF-8编码之间存在冲突。要解决这个问题，最直接且有效的方法是统一命令行环境的编码为UTF-8，或者干脆切换到一个对UTF-8支持更好的现代终端。
在Windows环境下，解决Composer字符编码问题，可以从几个层面入手，我通常会根据情况选择不同的方案。
为什么会出现Composer字符编码问题？
说实话，这几乎是所有在Windows CMD下搞开发的人都绕不开的“经典”问题。简单来说，Windows的CMD，骨子里还是带着点历史包袱，它默认的字符编码常常是GBK（或GB2312），这是一种主要针对简体中文设计的编码。而现代的软件开发，包括PHP、Composer，以及我们日常写的代码文件，几乎都统一使用UTF-8编码。
这两种编码一旦“撞”在一起，就像两种语言不通的人在对话，自然就出现了乱码。比如，Composer在输出一些包含中文的包名、描述，或者在安装过程中遇到文件名、目录名有中文时，CMD就可能无法正确解析这些UTF-8字符，显示成一堆问号或者奇怪的符号。更糟的是，有时候这不仅仅是显示问题，它还会导致Composer无法正确识别路径，从而引发安装失败或者依赖解析错误。这不仅仅是看着不舒服，是实实在在影响开发流程的。
临时解决方案：chcp 65001
的正确用法与局限性
最快、最直接的止痛药，就是使用
chcp 65001这个命令。
chcp是“Change Code Page”的缩写，而
65001就是UTF-8编码的代码页。
当你遇到Composer乱码时，可以在运行Composer命令之前，先在CMD里输入：
chcp 65001
然后，再执行你的Composer命令，比如：
chcp 65001 composer install
或者，更简洁一点，用
&&连接：
chcp 65001 && composer install
这样，当前CMD窗口的编码就会被临时切换到UTF-8，Composer的输出通常就能正常显示了。
不过，这个方法有个明显的局限性：它只对当前的CMD会话有效。你关闭了CMD窗口再打开，或者新开一个CMD窗口，编码又会变回默认的GBK。每次都要手动输入一遍，时间久了确实有点烦。而且，有些老旧的程序或者批处理脚本可能并不适应UTF-8环境，你切换编码后，它们反而可能出现乱码。所以，这更像是一个“应急”方案，适合偶尔用一下，但绝不是长久之计。
长期解决方案：告别CMD，拥抱现代终端
我个人觉得，要彻底解决这个问题，最好的办法就是“弃用”Windows自带的CMD，转投更现代、对UTF-8支持更好的终端模拟器。这不仅仅是为了Composer，也是为了整个开发体验的提升。
- Git Bash： 如果你安装了Git for Windows，那么你已经拥有了一个非常棒的终端——Git Bash。它提供了一个类Linux的Shell环境，对UTF-8的支持非常好，而且自带了许多Linux命令，用起来非常顺手。我大部分时间都是在Git Bash里进行开发操作。
- Windows Terminal： 这是微软官方出品的现代终端，集成了CMD、PowerShell、WSL等多种Shell，并且原生支持UTF-8。你可以自定义主题、字体，支持多标签页，体验非常流畅。安装也很简单，直接从Microsoft Store下载即可。
- WSL (Windows Subsystem for Linux)： 如果你对Linux环境比较熟悉，或者项目本身就更偏向Linux部署，那么WSL是终极解决方案。它让你能在Windows里运行一个完整的Linux发行版（如Ubuntu），Composer在WSL里运行，完全就是Linux环境，自然不会有Windows CMD的编码问题。
切换到这些终端后，你会发现字符编码问题几乎不再出现，而且它们在显示效果、快捷键、扩展性方面都比CMD强太多了。这不仅仅是解决了乱码，更是提升了整体的工作效率和舒适度。
针对特殊情况：Composer输出乱码的进一步排查与应对
尽管切换终端或者使用
chcp 65001能解决大部分问题，但偶尔我也会遇到一些“顽固”的乱码。这时候，就需要进一步排查了：
-
检查PHP的
default_charset
配置： 在php.ini
文件中，确保default_charset
被设置为UTF-8
。虽然这个配置更多影响的是PHP脚本自身的输出，但如果Composer依赖的某个PHP脚本在处理字符串时没有明确指定编码，这个全局设置也可能影响最终的输出。default_charset = "UTF-8"
-
文件本身的编码： 有时候，问题不在于终端或Composer，而是你项目中的某些文件（比如
composer.json
或者某个包含中文的PHP文件）本身就不是UTF-8编码。这在团队协作时，如果有人用了非UTF-8的编辑器保存了文件，就可能发生。可以用Notepad++、VS Code等编辑器打开文件，检查并确保其编码为UTF-8。 -
Composer缓存： 偶尔，Composer的缓存可能也会引发一些奇怪的问题。尝试清除Composer的缓存，然后重新运行命令：
composer clear-cache
-
环境变量： 检查系统或用户环境变量中是否有与编码相关的设置，例如
LANG
、LC_ALL
等。在Windows下，这些通常不是主要原因，但在某些特定配置下也可能干扰。
这些更深层次的排查，通常是在前面那些常见方案都无效时才会考虑。但多数情况下，切换到现代终端，就能一劳永逸地解决Composer在Windows CMD下的字符编码烦恼了。
