为何OpenLayers的optionsFromCapabilities仅支持WMTS，WMS无对应方法？

OpenLayers 针对 WMTS 提供optionsFromCapabilities便捷方法、却没有为 WMS 实现同类型能力，本质是两类服务的规范特性、使用场景存在本质区别，并非功能遗漏：

• 首先是WMTS的规范特性决定了它天生适配自动参数生成的逻辑：WMTS是OGC定义的强契约型瓦片服务规范，服务和客户端之间的出图规则是完全固定的——瓦片矩阵集、层级编码、瓦片尺寸、支持的坐标系、服务端预渲染的缓存范围都是capabilities文档里明确定义的枚举值，capabilities中的参数和实际发瓦片请求需要的参数是一一映射的，不存在歧义，完全可以把解析逻辑封装成通用方法，输出的配置可以直接拿来创建图层，不需要用户额外调整。
• 其次是WMS的规范特性决定了通用自动参数生成逻辑没有实用价值：WMS是动态出图的灵活型服务，capabilities文档只用来声明服务的能力边界，并不会和客户端形成固定的出图契约：
  • WMS的能力列表里会罗列几十种支持的坐标系，实际请求要选哪个坐标系完全取决于你当前地图的投影配置，这个选择逻辑是和前端地图的全局绑定状态相关的，框架没法替用户做最优选择
  • WMS会罗列一长串支持的输出图片格式（PNG、JPEG、WebP等），选哪种格式取决于业务对透明背景、压缩率、浏览器兼容性的要求，没有全局通用的默认最优值
  • WMS支持大量可自定义的请求参数：自定义SLD样式、时间维度过滤、CQL空间过滤、高程值、图层叠加顺序、比例尺范围等等，这些参数根本不会在capabilities文档里预定义，就算框架硬生成默认配置，也90%不符合实际业务需求
• 最后是OpenLayers的历史设计路径影响：WMS是OpenLayers从早期版本就开始支持的核心服务类型，从设计之初就定位为“用户按需传参”的灵活服务——毕竟WMS的使用场景跨度极大，有人用它加载静态单图层，有人用它做动态空间查询，有人用它对接自定义样式的渲染服务，框架根本没法封装一套覆盖所有场景的自动参数生成逻辑，硬做反而会引入大量不可预期的兼容问题。

虽然没有开箱即用的optionsFromCapabilities方法，但OpenLayers内置了标准的WMS capabilities解析能力，用户不需要手写XML解析逻辑：

• 可以直接使用内置的WMSCapabilities格式类，把获取到的capabilities XML文档解析成结构化的JSON对象
• 只需要从结构化对象里按需提取需要的参数（服务地址、目标图层名称、匹配当前地图投影的坐标系代码、业务选定的输出格式），手动组装WMS图层的配置即可

很多开发者觉得这是功能缺失，实际上WMS的使用灵活性远高于WMTS，哪怕框架硬实现了自动生成配置的方法，生成的默认配置也大概率会出现投影不匹配、格式不对、样式不符合需求的问题，反而会给开发者增加调试成本。

内容的提问来源于stack exchange，提问作者Patrik Jajo Jajcay