使用服务账号创建Google日历事件无法修改创建者名称

核心原因 #

• creator、organizer属于日历事件资源的只读输出字段，你在调用insert接口创建事件时传入的这两个字段的自定义值，会被Google Calendar服务直接丢弃，不会写入事件数据。
• 事件的创建者、组织者身份完全由鉴权上下文决定，也就是你JWT配置中模拟的主体账号email@domain.com，无法通过API传参修改这两个属性的实际值。
• 服务账号通过域委派模拟用户身份调用接口时，邀请邮件、事件详情里的显示名读取逻辑和普通用户前端操作的逻辑不一致：不会读取你在Google账号个人资料页设置的昵称，默认优先读取对应日历的配置名、Workspace目录的用户姓名，个人Gmail账号场景下默认截取邮箱@前缀作为显示名。

可行解决方案 #

场景1：使用Google Workspace企业域账号 #

• 配置全局显示名：进入Workspace管理后台的「目录-用户」列表，找到被模拟的email@domain.com账号，填写正确的「名/姓」字段，保存后等待目录同步（最长等待24小时），后续新建事件的邀请发件人、事件组织者就会显示你配置的姓名。
• 配置单日历显示名：进入对应Google日历的「设置和共享」页面，直接修改日历名称，该日历下创建的所有事件组织者都会显示这个日历名，该方法你已验证可生效。

场景2：使用个人普通Gmail账号 #

• 该场景下目前没有官方支持的自定义创建者/组织者显示名的方案，服务端固定截取邮箱@前缀作为显示名，属于接口已知限制，无合法绕过方式。

其他替代实现思路 #

• 如果你需要邀请邮件显示用户自己配置的账号昵称，放弃服务账号域委派模式，改用OAuth2.0授权码模式，让用户在前端手动完成账号授权，用用户自有凭据创建事件，此时邀请发件名会读取用户端配置的发件人信息，和用户手动在网页端创建事件的显示效果完全一致。
• 如果你仅需要在事件详情中向参会人展示自定义的创建方信息，不要占用creator字段，可将自定义名称写在事件description字段的开头位置，参会人打开事件详情即可看到。
• 不要尝试在请求中传入creator.email、organizer.email修改身份主体，这类参数要么被服务端直接忽略，要么会触发403权限错误。

注：所有第三方社区流传的修改请求头、强行覆写返回字段的方法均无法生效，因为显示名的渲染逻辑在Google服务端完成，客户端传参无法干预。

内容的提问来源于stack exchange，提问作者Bhavik Narang