【AI-Review】【建议】【软件设计】【其他软件设计问题】README中mediacodec-hevc选项移除与crash修复无关

● 问题：README.md和README_zh.md中移除 mediacodec-hevc 选项文档的变更与本PR的核心目标（修复callback ref被异步delete导致的use-after-free crash）无关。混合不相关变更会增加代码审查难度，也不利于后续git bisect定位问题。

● 影响：建议。不影响功能，但降低了变更的原子性和可追溯性。

● 建议：将 mediacodec-hevc 文档移除拆分为独立提交，并在commit message中说明移除原因（如该选项已被 mediacodec-all-videos 覆盖、不再独立支持等）。

【AI-Review】【严重】【基础代码问题】【稳定性问题】queueRefCleanup降级路径在非JS线程调用napi_delete_reference，可能导致crash

● 问题：queueRefCleanup函数（第91-109行）在napi_get_uv_event_loop返回null（第95行）或work分配失败（第101行）时，直接在当前线程调用napi_delete_reference(env, ref)作为降级处理。然而queueRefCleanup是从onSurfaceDestroyedCB调用的，XComponent回调可能在非JS线程执行。NAPI规范要求napi_delete_reference必须在JS线程（拥有napi_env的线程）上调用，在非JS线程调用可能导致内存损坏或crash。

● 影响：严重。虽然在正常情况下napi_get_uv_event_loop不会返回null、内存分配通常也会成功，但在极端场景（如JS引擎正在关闭、内存不足）下降级路径会被触发，而在非JS线程调用NAPI API可能导致不可预测的crash，且此类问题极难复现和定位。

● 建议：降级路径不应直接调用napi_delete_reference，而应记录警告并接受ref泄漏作为安全降级（ref泄漏比在错误线程调用NAPI API安全得多）。或者，可以在CleanupContext中存储足够的信息，由JS线程的下一个回调周期来清理：

if (loop == nullptr) {
    LOGE("napi-->queueRefCleanup: loop null, ref leaked to avoid unsafe NAPI call");
    // napi_delete_reference(env, ref);  // 移除：在非JS线程调用不安全
    return;
}

【AI-Review】【一般】【基础代码问题】【稳定性问题】after_message错误路径中callbackRef未被清理

● 问题：在 after_message 第112-122行，当 napi_get_reference_value 返回失败或 callback 为nullptr时，函数直接返回并释放了 context->obj、context 和 work，但没有删除 callbackRef。此时 IJKPlayerNapi::callBackRefMessage_ 仍指向该引用。后续 messageCallBack 会继续使用同一个失效的引用，导致 after_message 在每次回调时重复进入错误路径，消息永远无法送达JS层，且无任何日志提示需要重新设置监听器。

● 影响：一般。如果JS回调被GC或引用失效，消息回调将静默失败，用户无法收到播放器事件通知（如播放完成、错误等），且难以排查原因。

● 建议：在 after_message 的错误路径中，当检测到 callback == nullptr（引用有效但底层JS对象已被GC）时，设置一个标志或输出更明确的告警日志，提示应用层需要重新调用 setMessageListener。例如：

if (refStatus != napi_ok || callback == nullptr) {
    LOGE("napi-->after_message: callback reference invalid, setMessageListener should be called again");
    // ...
}

【AI-Review】【严重】【基础代码问题】【多线程问题】after_message持有的napi_ref可能已被异步删除导致use-after-free

● 问题：messageCallBack(第186行)通过getInstanceLocked获取env和ref的拷贝，存入CallbackContext后通过uv_queue_work调度到after_message。但在调度期间，onSurfaceDestroyedCB可能执行了queueRefCleanup(savedEnv, savedRef)，该函数也是通过uv_queue_work在同一event loop上调度cleanup_message_ref来删除ref。由于after_message和cleanup_message_ref都在主线程event loop上执行，它们的执行顺序由libuv调度决定。如果cleanup_message_ref先执行删除了ref，之后after_message执行napi_get_reference_value时操作的是已删除的ref，将导致crash或未定义行为。

关键时序：messageCallBack中获取ref拷贝 → uv_queue_work(after_message) → onSurfaceDestroyedCB中queueRefCleanup → uv_queue_work(cleanup_message_ref) → libuv按调度顺序执行callback → 若cleanup_message_ref先执行，ref被删除 → after_message对已删除ref调用napi_get_reference_value。

● 影响：严重。在Surface销毁与消息回调并发场景下，可能导致对已释放napi_ref的操作，引发native crash。

● 建议：考虑以下方案之一：

1. 在onSurfaceDestroyedCB中，将ref从instance移出保存到局部变量后，不要立即queueRefCleanup，而是先检查是否有pending的after_message任务。可以使用引用计数机制：instance维护一个pendingCallbackCount_，messageCallBack递增，after_message递减，onSurfaceDestroyedCB等待计数归零后再清理ref。
2. 使用napi_reference_ref/napi_reference_unref管理ref的生命周期。在messageCallBack中napi_reference_ref增加引用计数，在after_message中napi_reference_unref减少引用计数，当引用计数归零时才真正删除。

【AI-Review】【严重】【基础代码问题】【多线程问题】onSurfaceDestroyed()在持有mapMutex_锁时被调用，存在死锁风险

● 问题：onSurfaceDestroyedCB中第1204行instance->onSurfaceDestroyed(component, window)在持有mapMutex_锁的情况下被调用。而getInstance()（第1280行）也会获取mapMutex_锁。当前onSurfaceDestroyed()实现为空（仅打日志），不会触发死锁。但如果未来onSurfaceDestroyed()的实现中需要调用getInstance()或任何其他获取mapMutex_的函数，将导致同一线程重复获取非递归互斥锁，造成死锁。

● 影响：严重。当前不会触发，但这是一个脆弱的设计——后续对onSurfaceDestroyed()的任何扩展都可能无意中引入死锁。由于mapMutex_是std::mutex（非递归锁），同一线程重复加锁是未定义行为，通常直接死锁。

● 建议：将instance->onSurfaceDestroyed(component, window)移到锁作用域之外执行。onSurfaceDestroyed()不依赖map的状态，仅需component和window参数，因此可以安全地在释放锁后调用：

{
    std::lock_guard<std::mutex> lock(IJKPlayerNapi::mapMutex_);
    auto it = IJKPlayerNapi::ijkPlayerNapi_.find(id);
    if (it == IJKPlayerNapi::ijkPlayerNapi_.end()) {
        LOGE("napi-->onSurfaceDestroyedCB instance not found");
        return;
    }
    instance = it->second;
    if (instance->callBackRefMessage_ != nullptr && instance->envMessage_ != nullptr) {
        savedEnv = instance->envMessage_;
        savedRef = instance->callBackRefMessage_;
        instance->callBackRefMessage_ = nullptr;
        instance->envMessage_ = nullptr;
    }
    IJKPlayerNapi::ijkPlayerNapi_.erase(it);
}
instance->onSurfaceDestroyed(component, window);

【AI-Review】【一般】【基础代码问题】【多线程问题】onSurfaceDestroyedCB中delete instance后ijkPlayerNapiProxy_可能仍被其他线程引用

● 问题：onSurfaceDestroyedCB(第1213-1217行)在锁外执行delete instance->ijkPlayerNapiProxy_和delete instance。但getInstance被45处调用（包括NAPI回调函数如stop、pause、reset、release等），这些调用虽然通过getInstance的锁保护能获取到instance指针，但使用instance指针（如调用ijkPlayerNapiProxy_->IjkMediaPlayer_stop()）时锁已释放。如果此时onSurfaceDestroyedCB执行了delete instance，这些NAPI回调将访问已释放内存。

虽然onSurfaceDestroyedCB先从map中erase了instance，新调用getInstance不会获取到该instance，但已在锁内获取到instance指针的旧调用仍会继续使用它，与onSurfaceDestroyedCB中的delete存在竞态。

● 影响：一般。在Surface销毁与NAPI操作并发场景下，可能导致use-after-free。但由于XComponent回调通常在主线程执行，而NAPI调用也在主线程，实际并发概率取决于是否有异步操作在work线程中引用instance（如stopAsync和releaseAsync中的async_work回调）。

● 建议：考虑使用std::shared_ptr/std::weak_ptr管理IJKPlayerNapi实例的生命周期。map存储std::shared_ptr，使用方持有std::weak_ptr或std::shared_ptr，确保实例在所有使用者完成操作后才被销毁。或者引入引用计数机制，在onSurfaceDestroyedCB中仅标记待销毁，在引用计数归零时才真正delete。

【AI-Review】【严重】【基础代码问题】【多线程问题】getInstance加锁后释放锁到使用instance之间存在use-after-free窗口

● 问题: getInstance（第1278行）虽然已加锁保护map的查找和插入操作，但锁在函数返回时就释放了。调用者拿到IJKPlayerNapi*裸指针后，在锁外使用该指针访问成员（如ijkPlayerNapiProxy_）。而onSurfaceDestroyedCB在锁内执行erase和锁外执行delete instance，存在以下竞态：

1. 线程A调用getInstance(id)获取instance指针，锁释放
2. 线程B执行onSurfaceDestroyedCB，加锁 → erase → 释放锁 → delete instance
3. 线程A使用instance指针访问ijkPlayerNapiProxy_->xxx()，此时instance已被delete

这个问题在所有45个调用getInstance的NAPI函数中都存在（如setDataSource、prepareAsync、start、stop等），因为它们都在锁外持有并使用instance指针。

● 影响: 严重。在Surface销毁与任何NAPI调用并发时，都可能导致use-after-free崩溃。这是此PR未完全解决的核心问题——锁只保护了map本身的一致性，但没有保护instance对象的生命周期。

● 建议: 考虑使用std::shared_ptr<IJKPlayerNapi>管理instance生命周期，map中存储shared_ptr，调用者获取shared_ptr副本。这样onSurfaceDestroyedCB从map中erase后，只要还有调用者持有shared_ptr，instance就不会被delete。或者引入引用计数机制，在instance上标记"正在销毁"状态，让其他调用者检查后提前返回。