我太懂你这种憋屈的感觉了——所有配置都对着文档查了三遍，URI能下载能打开，容器背景也乖乖显示，日志里连个报错都没有，可PDF就是死活不出来。结合你贴的日志和代码，我帮你梳理几个最可能的坑和修复方案，按优先级从高到低来：

1. 最可能的原因：Fragment参数键不匹配 #

你现在是手动给PdfViewerFragment的arguments塞"uri"键，但官方的PdfViewerFragment根本不认这个自定义键啊！它有自己固定的参数常量PdfViewerFragment.URI_ARG，或者更省心的是直接用官方提供的newInstance方法创建实例。

这就好比你给快递员留了错误的收件人名字，他拿着包裹找不到人，自然不会送货上门。

修复代码：
把你创建Fragment的代码替换成下面二选一：

// 方式一：用官方newInstance方法（最推荐）
val newFragment = PdfViewerFragment.newInstance(uri)

// 方式二：手动传参时用官方常量键
val newFragment = PdfViewerFragment()
newFragment.arguments = bundleOf(PdfViewerFragment.URI_ARG to uri)

2. 检查Fragment事务的提交逻辑 #

你在AndroidView的update块里处理Fragment事务，这里有两个容易踩的坑：

坑A：硬编码的FragmentContainerView ID #

日志里显示你给容器设置的id是1，这太容易和其他View的id冲突了！Fragment事务是靠id找容器的，冲突了就会出现“明明加了Fragment但渲染到别的地方去了”的诡异情况。

修复：用系统生成的唯一ID：

FragmentContainerView(themeContext).apply {
    id = View.generateViewId() // 生成全局唯一的View ID
}

坑B：异步提交事务导致的延迟 #

你现在用的是默认的commit()，这是异步提交的，在Compose的重组节奏里很容易出现Fragment还没初始化好，Compose已经完成重组的情况，看起来就像没加载。

修复：用同步提交的commitNow()：

activity.supportFragmentManager.commitNow {
    replace(fragmentContainerView.id, newFragment, fragmentTag)
}

另外，当URI变化时，要先移除旧的Fragment再添加新的——PdfViewerFragment不支持动态更新URI，旧的Fragment会一直占着位置，新的加不进去。完整的update块逻辑可以改成这样：

update = { fragmentContainerView ->
    Log.d("MyPdfViewer", "Update called. URI: $uri, FragmentContainerView ID: ${fragmentContainerView.id}")
    if (uri != null) {
        val existingFragment = activity.supportFragmentManager.findFragmentByTag(fragmentTag)
        if (existingFragment != null) {
            // 如果已存在Fragment且URI不同，先移除旧的
            val existingUri = existingFragment.arguments?.getParcelable<Uri>(PdfViewerFragment.URI_ARG)
            if (existingUri != uri) {
                activity.supportFragmentManager.commitNow {
                    remove(existingFragment)
                }
                // 添加新Fragment
                val newFragment = PdfViewerFragment.newInstance(uri)
                activity.supportFragmentManager.commitNow {
                    replace(fragmentContainerView.id, newFragment, fragmentTag)
                }
            }
        } else {
            Log.i("MyPdfViewer", "Fragment with tag $fragmentTag not found. Adding new PdfViewerFragment.")
            val newFragment = PdfViewerFragment.newInstance(uri)
            activity.supportFragmentManager.commitNow {
                replace(fragmentContainerView.id, newFragment, fragmentTag)
            }
        }
    } else {
        Log.w("MyPdfViewer", "Update called but URI is null. Not doing anything.")
    }
}

3. 排查主题配置的问题 #

你用了自定义的PdfViewerTheme，如果这个主题没有正确继承兼容的父主题，或者覆盖了影响Fragment渲染的属性，也会导致PDF不显示。

调试方法：先暂时去掉自定义主题，用Activity的默认主题测试：

val themeContext = activity // 替换掉ContextThemeWrapper(activity, R.style.PdfViewerTheme)

如果这样能显示PDF，说明你的自定义主题有问题——比如没继承Theme.MaterialComponents或Theme.AppCompat，或者把android:windowBackground设成了透明，导致PDF渲染了但和背景融为一体看不见。

4. 版本太老的锅！ #

你用的是1.0.0-alpha10，这是2021年左右的早期alpha版本，当时Compose和PdfViewer的集成还一堆bug。我之前踩过这个坑，升级到新版本就好了。

修复：把依赖换成最新的alpha版本（现在最新是1.1.0-alpha03）：

def composeBom = platform('androidx.compose:compose-bom:2025.09.00')
// 升级pdf相关依赖
implementation "androidx.pdf:pdf-viewer:1.1.0-alpha03"
implementation "androidx.pdf:pdf-compose:1.1.0-alpha03"
implementation "androidx.pdf:pdf-viewer-fragment:1.1.0-alpha03"

5. 最后一招：绕过FileProvider调试 #

如果上面的方法都没用，你可以先绕过FileProvider，用File URI直接加载（仅限调试环境！正式环境不能用），排查是不是FileProvider的问题：

// 调试用：直接用缓存文件的绝对路径生成URI
val tempFile = File(activity.cacheDir, "temp_pdf_viewer.pdf")
val testUri = Uri.fromFile(tempFile)
val newFragment = PdfViewerFragment.newInstance(testUri)

如果这样能显示PDF，说明问题出在FileProvider的配置上——再去检查你的paths XML配置，确保my_cache_files确实指向了应用的缓存根目录：

<paths>
    <cache-path name="my_cache_files" path="." />
</paths>

按这个顺序排查，90%的概率能解决问题！先从第一个点开始，因为参数键不匹配是这个场景下最常见的低级错误。