根据你描述的情况——本地运行日志正常，但部署后日志文件既不生成也无法被捕获，结合你的logback.xml配置，我整理了几个最可能的原因和对应的解决办法：

• 绝对路径不兼容部署环境
  你配置里的日志路径是d:/Logs/truprovider.log，这是Windows特有的盘符路径。如果你的部署服务器是Linux/Unix系统，根本不存在D盘；就算是Windows服务器，部署应用的系统用户也可能没有访问D盘的权限。
  建议换成相对路径或动态路径：

  <!-- 相对路径：相对于应用的工作目录 -->
  <file>./Logs/truprovider.log</file>
  <!-- 动态路径：优先使用系统变量LOG_DIR，不存在则用当前目录下的Logs -->
  <file>${LOG_DIR:-./Logs}/truprovider.log</file>
  

  记得同步修改滚动策略里的FileNamePattern路径。

• 日志目录权限不足
  就算路径正确，部署应用的用户可能没有创建Logs目录或写入文件的权限。比如在Linux服务器上，若应用以tomcat用户运行，但日志目录是用root权限创建的，tomcat用户就无法写入。
  解决办法：提前创建日志目录并赋予对应权限，例如Linux下执行：

  mkdir -p /opt/your-app/Logs
  chown tomcat:tomcat /opt/your-app/Logs
  

• Logback配置文件未被正确加载
  部署后可能logback.xml没有被放到正确的位置，导致应用使用了Logback的默认配置而非你的自定义配置。Logback默认从classpath根目录加载配置文件，需确保打包时将logback.xml放入WEB-INF/classes（Web应用）或jar包的根目录。
  可以添加JVM启动参数-Dlogback.debug=true，查看Logback的加载日志，确认是否成功读取到你的配置文件。

• Logger范围不匹配
  你配置的<logger name="com.cts.emblem.batch" level="INFO" additivity="false">仅让该包下的日志同时输出到控制台和文件，而root logger只输出到控制台。如果你的业务类不在com.cts.emblem.batch包下，日志只会输出到控制台，不会写入文件。
  解决办法：要么确认业务类包名与配置的logger name一致，要么将文件appender添加到root logger：

  <root level="INFO">
    <appender-ref ref="STDOUT" />
    <appender-ref ref="FILE" />
  </root>
  

• 滚动策略干扰基础文件输出
  虽然可能性较低，但FixedWindowRollingPolicy的配置可能导致初始文件生成异常。可以暂时注释掉滚动策略相关配置，先测试基础的文件输出是否正常，排除滚动策略的影响。

按这个顺序排查，应该能快速定位问题。

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