我之前也碰到过php-fpm下php.ini配置不生效的坑，给你几个实用的排查步骤，应该能定位到问题：

• 检查是否存在配置覆盖
  PHP-FPM除了主配置文件/etc/php/7.1/fpm/php.ini，还可能加载conf.d目录下的额外配置文件，或者每个FPM池（比如/etc/php/7.1/fpm/pool.d/www.conf）里的单独设置。这些地方的sendmail_path优先级更高。你可以用CLI命令模拟FPM的配置加载：

  php -c /etc/php/7.1/fpm/php.ini -i | grep sendmail_path
  

  把输出结果和phpinfo()里的sendmail_path对比，如果不一致，说明有其他配置文件覆盖了你的设置。

• 检查FPM池的php_admin_value设置
  打开你的FPM池配置文件（通常是pool.d/www.conf），搜索sendmail_path相关配置。如果看到类似php_admin_value[sendmail_path]的行，这会直接覆盖php.ini里的设置，而且无法被用户代码修改。把它改成你需要的MailHog路径，比如：

  php_admin_value[sendmail_path] = "/usr/local/bin/mailhog sendmail your-test-email@example.com"
  

  修改后记得重启php7.1-fpm服务。

• 验证MailHog命令的可用性与权限
  确保你设置的MailHog路径正确，并且PHP-FPM运行用户（通常是www-data）有权限执行它。先通过which mailhog找到正确的命令路径，然后测试：

  sudo -u www-data /path/to/mailhog sendmail test@example.com
  

  如果执行报错，要么是路径不对，要么是权限不足，需要调整文件权限或者相关配置。

• 确认PHP-FPM确实重启成功
  有时候看似重启了服务，但进程其实没更新。你可以用ps aux | grep php-fpm查看进程PID，重启后PID应该变化；或者用systemctl status php7.1-fpm检查服务状态，确认启动时间是你重启后的时间。如果用的是旧的service命令，确保执行service php7.1-fpm restart后服务处于running状态。

• 临时在代码中验证配置值
  写一个简单的PHP文件放在Web目录下：

  <?php
  echo "当前sendmail_path: " . ini_get('sendmail_path');
  ?>
  

  通过浏览器访问这个文件，看看输出的是不是你设置的路径。如果不是，说明配置确实没加载；如果是，那可能是MailHog本身的运行问题（比如没启动），但你提到CLI环境生效，所以大概率还是配置覆盖的问题。

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