如何组合两个原生HTML表单元素实现一体化输入选择效果

不用搞复杂的自定义元素或者contenteditable方案，原生HTML+CSS+JS完全可以实现，可控性高、踩坑少，整体思路如下：

组合组件实现 #

城市输入不要用textarea，单行输入用普通<input>即可，textarea是为多行文本设计的，不适合这个场景。
核心思路是用一个容器div把输入区、选择区包起来，给容器做统一的样式，内部元素去掉默认样式，视觉和交互上自然就是一体化组件：

• 外层容器设置display: flex布局，加统一的边框、圆角、内边距，用:focus-within伪类实现内部元素聚焦时，容器整体显示高亮边框，不需要额外JS处理聚焦态
• 输入框设置flex: 1占满容器剩余宽度，去掉默认边框、背景、轮廓线，字体大小和组件整体匹配
• 不要用原生select，原生select的下拉弹出层样式无法跨浏览器统一，自己写一个简单的选择按钮即可：点击切换选项浮层的显示/隐藏，浮层用绝对定位挂在容器下方，样式可以完全自定义
• 输入框和选择按钮之间加1px宽的竖线做视觉分隔，和通用组合搜索组件的交互习惯一致

基础结构参考：

<div class="search-group">
  <input type="text" class="city-input" placeholder="输入城市名">
  <span class="split-line"></span>
  <div class="deal-type">
    <span class="current-type">买房</span>
    <ul class="type-options">
      <li>买房</li>
      <li>租房</li>
    </ul>
  </div>
</div>

核心CSS参考：

.search-group {
  display: flex;
  align-items: center;
  width: 500px;
  height: 48px;
  border: 1px solid #e5e5e5;
  border-radius: 8px;
  padding: 0 16px;
  transition: border-color 0.2s ease;
}
.search-group:focus-within {
  border-color: #2563eb;
}
.city-input {
  flex: 1;
  height: 100%;
  border: none;
  outline: none;
  font-size: 16px;
  background: transparent;
}
.split-line {
  width: 1px;
  height: 24px;
  background-color: #e5e5e5;
  margin: 0 16px;
}
.deal-type {
  position: relative;
  cursor: pointer;
  font-size: 16px;
}
.type-options {
  position: absolute;
  top: calc(100% + 8px);
  right: 0;
  min-width: 80px;
  padding: 6px 0;
  margin: 0;
  list-style: none;
  background: #fff;
  border-radius: 8px;
  box-shadow: 0 2px 16px rgba(0,0,0,0.1);
  display: none;
}
.type-options.show {
  display: block;
}
.type-options li {
  padding: 8px 20px;
}
.type-options li:hover {
  background-color: #f5f5f5;
}

JS部分只需要处理选择按钮的点击切换、点击外部区域关闭浮层、选中选项后更新当前显示文本即可，逻辑不超过20行。

自动补全功能实现 #

不要被contenteditable的方案误导，用普通input做输入，所有自动补全逻辑都可以正常运行，不存在兼容性问题：

• 自动补全的下拉列表和上面的类型选择浮层逻辑一致，用绝对定位挂在搜索组容器下方即可，监听input的输入事件，拿到当前输入内容做匹配，把匹配到的城市结果渲染到下拉列表里，点击选项就把内容填充到输入框
• 如果只需要匹配全国地级/县级城市名，总数据量也就3000条以内，完全可以把城市列表存在本地，用前缀匹配做搜索，响应速度极快，不需要接入任何第三方服务
• 如果后续需要做小区、商圈级别的搜索，数据量较大时再考虑接入搜索服务即可，普通input的输入内容可以正常被JS获取，不管接什么API都不会有适配问题，不需要用contenteditable
• 初期完全没必要上Algolia这类重型搜索方案，本地匹配足够覆盖需求，后续要替换搜索服务时只需要改数据请求的逻辑，UI层不用动，迁移成本很低

避坑提示 #

• 非必要不要用contenteditable做普通输入，这个属性的光标控制、内容过滤、移动端兼容坑非常多，普通input能满足需求的情况下完全没必要碰
• 非必要不要硬改原生select的样式，尤其是下拉弹出层部分，跨浏览器兼容的调试成本远高于自己写一个简单的模拟选择组件
• 所有下拉浮层都要补充点击组件外部区域自动关闭的逻辑，符合用户的通用交互习惯

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