基于Direflow的Web组件嵌入站点如何获取userId与locale参数？

首先明确结论：你设想的locale="props.locale"这种写法完全不可行。
HTML原生标签的属性值本质是纯静态字符串，不会自动解析任何模板语法、变量引用，如果你这么写，Direflow开发的Web组件读取到的locale值就是字面量的"props.locale"，根本拿不到真实的用户ID和语言参数。

适配你当前场景的低复杂度实现方案 #

按照落地成本从低到高排序：

• 最匹配你现有代码的方案：由宿主站点在嵌入Web组件的环节，直接把动态参数值填充到标签属性上。
  不管宿主站点用什么技术栈，核心逻辑都是在需要挂载<service>组件的位置，先从宿主的用户状态存储里拿到真实的userId、locale值，再把这些值设置为自定义元素的属性。举个宿主侧的JS示例：

  // 从宿主站点自己的用户存储中取真实值
  const loginUserId = window.globalUserState.userId
  const currentLang = window.globalUserState.locale
  
  // 动态创建自定义元素，替换之前硬编码的静态标签
  const serviceComponent = document.createElement('service')
  serviceComponent.setAttribute('userId', loginUserId)
  serviceComponent.setAttribute('locale', currentLang)
  // 把组件插入到页面指定位置
  document.querySelector('#service-container').appendChild(serviceComponent)
  

  这种方式完全适配Direflow的属性接收逻辑——Direflow默认就是基于自定义元素的HTML属性做参数入参的，你的组件端不需要做任何代码修改。
• 如果你的嵌入位置是服务端渲染的页面，直接让后端在输出最终HTML的时候，把硬编码的属性值替换成数据库/会话中存的真实用户值就行，最终渲染到浏览器的HTML直接是带真实参数的标签，效果和上面的动态创建完全一致。

新手容易踩的风险提醒 #

• 不要尝试让Web组件主动读取宿主站点的全局变量拿用户数据：这种方式会让两个系统强耦合，只要宿主站点调整了全局变量的命名、存储位置，你的组件就会直接失效；更重要的是涉及用户身份数据的场景，强约束的属性传参边界能从机制上避免越权读取用户数据的风险，符合Web组件的解耦设计原则。
• 上线前一定要核对参数传递的准确性：因为你的组件涉及用户专属资源的访问，一旦属性传错userId，会直接出现跨用户看到他人私有数据的严重问题，不能沿用硬编码的测试值上线。

对应的学习方向指引 #

• 优先梳理Web Components原生规范中「自定义元素的属性读取、生命周期回调」的基础概念，搞清楚attribute和property的区别，这部分是包括Direflow在内所有Web组件开发框架的底层逻辑，不需要一开始就啃复杂框架文档。
• 了解Web Components的标准跨边界通信机制：除了属性传参，还可以通过自定义事件、Shadow DOM插槽实现和宿主站点的双向交互，全程不需要依赖宿主站点的内部技术栈。

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