\_param 不是标准 html 或 web api 的一部分，仅在特定插件系统（如旧版 flash、npapi 插件或定制音视频 sdk）中作为约定扩展参数存在，需插件主动解析，现代 web 平台已弃用该机制。
多媒体参数 _PARAM 标签不是标准 HTML 或 Web API 的一部分，它只在特定插件系统（如早期 Flash 插件、某些浏览器 NPAPI 插件、或定制音视频 SDK 的嵌入式环境）中作为约定用法存在。直接写 <param name="_PARAM" value="..."> 不会自动生效，必须由宿主插件主动读取并解析。
为什么 _PARAM 不是通用机制
浏览器对 <object></object> 或 <embed></embed> 中的 <param> 标签仅做透传，具体如何解释 name 和 value 完全取决于插件内部实现。比如旧版 VLC Web Plugin、RealPlayer、或某厂商自研播放器 SDK，才可能约定识别 _PARAM 作为扩展参数入口。
- 标准参数名如
src、autoplay、controls由浏览器/HTML 解析，_PARAM不在此列 - 若插件未实现
_PARAM解析逻辑，该标签会被完全忽略 - 现代 Web 平台（WebAssembly、MediaSource API、WebRTC）已弃用插件模型，
_PARAM几乎无适用场景
怎样让插件实际读取 _PARAM 值
关键不在 HTML 怎么写，而在插件代码里是否调用对应 API 获取参数。以典型 NPAPI 插件为例：
- 在插件初始化时调用
NP_GetValue或遍历NPObject的getproperty接口 - 检查是否有 name 为
_PARAM的<param>，然后手动解析其value字符串（常见为 JSON 格式） - 示例伪代码：
char* param_val = get_param_by_name("_PARAM");<br>if (param_val) {<br> parse_json_into_plugin_config(param_val);<br>}
替代方案：更可靠、可维护的传参方式
如果控制插件源码，优先避免依赖 _PARAM 这类非标约定；如果只能调用黑盒插件，需确认其文档是否明确定义了该行为。
- 用标准
<param>名称（如config、options）更易被其他开发者理解 - 通过 JavaScript 调用插件暴露的方法传参，例如：
pluginInstance.setConfig({volume: 0.8, autoplay: true}) - 若插件支持 URL 查询参数（如
src="player.dll?volume=0.8&mode=loop"），比_PARAM更直观且可调试
真正容易被忽略的是：插件是否真的实现了 _PARAM 解析 —— 很多所谓“支持”的插件其实只是把该标签当普通字符串收下，并未触发任何配置行为。调试时建议直接查看插件日志或源码中的 getparam / get_value 调用链。
