添加Gilroy-light.ttf报OSError文件未找到，配置ttf打包规则仍报错求助

按照实际开发踩坑频率从高到低依次排查即可：

• 核对代码内的字体引用路径和实际存放路径的匹配性
  开发环境下仅写文件名Gilroy-light.ttf能正常运行，是因为当前工作目录刚好和字体所在目录重合；但打包后应用的工作目录会发生变化，直接写相对文件名会导致搜索路径覆盖不到字体位置。
  解决方式：在应用初始化阶段，把字体所在的资源目录主动加入Kivy的资源搜索路径，再加载字体，示例代码：

  from kivy.resources import resource_add_path
  import os
  # 定位字体文件的实际存放目录，替换成你项目里字体所在的相对路径
  font_resource_dir = os.path.join(os.path.abspath(os.path.dirname(__file__)), "assets/fonts")
  resource_add_path(font_resource_dir)
  

• 验证字体文件是否真的被打进安装包
  仅在include_exts中添加ttf后缀不代表文件会被自动打包：需要确认ttf文件存放在项目源码目录的相对路径下，而非项目外的其他磁盘位置。
  可以在打包完成后，直接查看生成的安装包目录（如Windows打包后的dist目录、Android apk的assets目录），搜索目标ttf文件确认是否存在。如果没被打包，可以通过include_files规则显式声明字体文件的打包映射，避免遗漏：

  source.include_files = (
      ('assets/fonts/Gilroy-light.ttf', 'assets/fonts/Gilroy-light.ttf'),
  )
  

• 检查文件名的大小写匹配问题
  Windows/macOS开发环境对文件名大小写不做严格校验，哪怕代码里写的文件名和实际文件大小写有差异，开发阶段也能正常运行；但打包后运行在类Unix内核的系统（Android、Linux、iOS）下，大小写不匹配会直接触发文件不存在的错误。需要逐字符核对代码内引用的文件名和磁盘上的实际文件名，包括大小写、短横线连接、后缀名的大小写差异。
• 确认打包配置实际生效
  很多时候修改的source.include_exts配置行被前置的注释符#标记，导致配置根本没被打包工具读取。可以在打包日志里搜索ttf相关的包含规则，确认修改的配置已经被加载，而不是写在了无效的注释块中。

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