必须用 form 包裹 input[type="search"] 并设 role="search"，禁用 div 模拟；CSS 用 display: block + margin: 0 auto 居中，box-sizing: border-box 适配移动端；提交行为依场景选跳转或异步；需监听 click 主动 blur 防焦点残留。
用 form + input[type="search"] 套进卡片容器就行
HTML卡片本身不提供搜索能力，它只是视觉容器；搜索功能必须由语义化表单元素承载。直接把 form 放进 div 或 article 这类卡片结构里，是最轻量、最可靠的做法。
常见错误是试图用纯 div + span 模拟搜索框——这样既没语义，也丢失了原生 input[type="search"] 的行为（比如 iOS 自动唤起搜索键盘、清空按钮、历史记录等）。
- 必须用
form包裹，且建议加role="search"属性，方便屏幕阅读器识别 -
input的type必须是"search"，不是"text"—— 后者在 Safari 和部分安卓浏览器里不会显示清除图标 - 卡片内若含其他交互元素（如筛选按钮、分类标签），
form应只包裹搜索相关控件，避免 submit 行为误触其他逻辑
卡片内搜索框的宽度与对齐要靠 CSS 盒模型控制
卡片排版中搜索框“看起来居中”不等于“真正居中”。很多开发者用 text-align: center 包卡片再放 input，结果输入框内容左对齐、占位符偏移、响应式下错位——根源是没区分容器对齐和子元素尺寸控制。
正确做法是明确设置 input 的 width 或 max-width，并用 margin: 0 auto 配合 display: block 实现水平居中：
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
.card-search input[type="search"] {
display: block;
width: 100%;
max-width: 400px;
margin: 0 auto;
}
- 不要依赖父容器
text-align控制input位置，它只影响行内元素 - 移动端需加
box-sizing: border-box，否则 padding 会撑出卡片边界 - 若卡片用 Flex 布局，
input默认会拉伸，需加flex: 0 1 auto防止过度伸展
搜索提交后跳转或异步加载？得看卡片所处上下文
卡片里的搜索框不是孤立存在：它可能属于首页推荐区、侧边工具栏，或是独立搜索页的摘要卡片。提交行为必须匹配场景，不能一概而论。
- 作为导航入口（如顶部通栏卡片）：用
form的action和method="get"，跳转到 /search?q=xxx，利于 SEO 和浏览器历史回退 - 作为功能模块嵌入（如仪表盘中的快速检索）：阻止默认 submit，用
fetch()调 API，渲染结果到同卡片内或相邻区域 - 若卡片本身可折叠/关闭，搜索框提交前应校验是否处于展开态，否则用户点 submit 没反应，容易以为功能失效
移动端键盘收起与焦点管理容易被忽略
在卡片中点击搜索框唤起软键盘后，用户常会点空白处或返回键收起键盘——但原生 input 不会自动 blur，导致后续点击卡片其他区域（如切换标签）时焦点残留、光标乱跳。
这不是样式问题，是事件流没兜住：
- 监听卡片容器的
click事件，判断点击目标是否非input且非其附属按钮（如清空图标），然后主动blur() - 避免用
touchstart替代click，iOS 上有 300ms 延迟，体验割裂 - 若卡片内有多个
input（如带高级筛选），blur 逻辑要排除当前激活项，否则刚点下一个框就又被 blur
卡片排版里搜索功能的复杂点不在视觉，而在它既是独立控件，又深度耦合容器状态、焦点生命周期和上下文行为——漏掉任意一环，用户就会觉得“这个搜索框不太听话”。
