Go net/http 筛选表单怎么做：查询回填、空结果状态与安全输出

后台列表页加个「按名称筛选」输入框，看起来只是读取 URL 里的 q，实际很容易碰到三个常见小问题：提交后输入框内容清空、没有匹配项时页面观感像出了故障、用户输入内容被当成HTML拼回页面引发异常。用 Go 的 net/http、net/url 和 html/template 就可以把整条链路捋清楚：参数先做规范化处理，结果和原始查询词一起交给模板，模板负责安全转义输出。

先把列表页拆成三个可验证状态

这个例子用内存切片模拟商品数据，页面只聚焦筛选流程，不会把数据库查询的细节混进模板逻辑里。访问 /products 时有三种状态：没有关键词显示全部商品，有关键词且命中显示过滤结果，有关键词但没有命中显示空状态。

这张图对应这一节内容：请求进入筛选逻辑后，分别走向“全部”“命中”和“空结果”三个页面状态。它不是页面装饰，排查回填问题时可以按这条路径逐个验收。

最小配方：Query、Items 和空状态一起传给模板

不要只把过滤后的切片传给模板，模板还需要知道用户刚才输入了什么，否则 value 属性无法回填。把数据定义成一个页面专用结构，状态会比传一堆孤立变量更容易检查。

页面处理器可以先读取并规范化 q，再把 Query、Items 和 HasResult 放进 ProductPage。当 q 超过 40 个字符时返回 400；正常请求则执行模板并记录渲染错误。这个小结构的关键不是字段多，而是让模板拿到足够的信息来区分“未筛选”和“筛选后为空”。

长度限制使用字符数而不是字节数，中文输入不会因为 UTF-8 一个字占多个字节而过早被拒绝。这里返回 400 是参数契约的一部分；如果产品希望宽松处理，也可以截断，但要在接口说明和测试里固定下来。

模板回填和空结果，不要交给前端补救

服务端渲染页面最稳妥的做法，是在第一次输出 HTML 时就把状态写完整。表单的 value 直接绑定 .Query，列表通过 range 展开。没有数据时不要输出空的列表容器，而是告诉用户当前词没有结果，并提供一个不带 q 的清空链接。

模板只保留一个判断链即可：表单的 value="{{.Query}}" 负责回填，{{if .Items}} 展示命中列表，{{else if .Query}} 展示空结果和 /products 清空链接，最后的 {{else}} 处理没有任何商品的初始状态。

html/template 会按 HTML 文本和属性上下文处理 .Query。例如用户输入带有尖括号或引号，页面中显示的是纯文本内容，不会被当成新的标签。这个安全边界建立在“模板变量正常输出”的前提上，不能为了显示一段富文本就随手换成不转义的输出类型。

第二张图绑定本节，展示“输入回填”和“无结果清空”两个视觉状态。真实页面验收时，分别输入 耳机、不存在的商品 和一串特殊字符，确认输入框内容与空状态都保持正常可读。

给筛选器补上大小写、空格和重复参数边界

过滤函数只做一件事：比较规范化后的名称。不要在模板里判断关键词，也不要让多个层同时裁剪字符串，否则出现问题时很难定位哪个环节改了用户输入。

func filterProducts(all []Product, raw string) []Product {
    needle := strings.ToLower(strings.TrimSpace(raw))
    if needle == "" {
        return all
    }

    out := make([]Product, 0, len(all))
    for _, item := range all {
        if strings.Contains(strings.ToLower(item.Name), needle) {
            out = append(out, item)
        }
    }
    return out
}

GET 查询天然允许重复参数，例如 ?q=耳机&q=键盘。Get 只取第一个值，适合这个单条件筛选器；如果以后扩展成多条件，应该显式读取 r.URL.Query()["q"] 并定义“全部匹配”还是“任意匹配”，不要让默认行为悄悄决定产品语义。

常见坑：样式、编码和错误响应

不要用字符串拼接输出用户输入

拼接