FCM本地化推送通知在Android/iOS端的运行行为咨询

以下结论基于FCM官方SDK默认实现、Android/iOS系统原生通知解析逻辑验证：

场景1：通知仅携带title_loc_key、body_loc_key参数，应用内未配置对应本地化键值资源 #

• Android端：通知不会被系统拦截丢弃，可正常展示。但系统查找不到匹配的本地化字符串时，会直接将传入的title_loc_key、body_loc_key的原始字符串值作为通知标题、正文展示给用户，不会展示空白内容。例如传入title_loc_key = "msg_received_title"但未配置对应资源时，用户看到的通知标题就是msg_received_title这串原始字符。
• iOS端：通知可正常送达展示，行为与Android端一致。系统找不到对应本地化键值时，不会做特殊兼容处理，直接将传入的loc_key原始值作为通知内容展示。

场景2：通知同时携带loc_key类本地化参数、标准title/body参数 #

• Android端：默认逻辑下不会自动回退到通用title/body。只要payload中携带了title_loc_key/body_loc_key，系统会优先尝试加载应用内对应的本地化资源；如果资源不存在，依旧按照场景1的逻辑直接展示loc_key原始字符串，不会主动读取你传入的通用title、body作为兜底。如果需要实现缺省回退能力，需要自行在自定义FirebaseMessagingService逻辑中判断资源是否存在，手动选择展示的内容。
• iOS端：默认逻辑与Android端完全一致，loc相关参数优先级高于通用title/body参数。系统会优先尝试匹配本地化资源，匹配失败时直接展示loc_key原始值，不存在自动回退到通用文本的默认逻辑。需要回退能力的话，要通过Notification Service Extension自定义修改通知内容实现。

补充说明：以上均为系统、FCM SDK的默认行为，如果你在客户端做了自定义通知拦截处理，可以自行修改优先级、兜底逻辑，不受默认规则限制。

内容的提问来源于stack exchange，提问作者Matěj Kos