起点：一个深夜派出所的问题

每个产品的起点，都不是一个想法，而是一个让你无法安睡的问题。

深夜十一点，派出所的灯还亮着。一位基层民警正在办理一起治安案件，他需要查询《治安管理处罚法》第四十三条的准确条文，确认处罚幅度，还要核对办案程序是否符合最新规定。他翻开厚重的法条汇编，在手机上搜索司法解释，在电脑上查看内部办案系统——三个屏幕，三套语言，三种逻辑。

这不是个例。在基层执法一线，法律查询、流程指引、文书规范，每一项都需要准确、及时、可信赖的参考。但现有的工具要么太重（专业法律数据库），要么太轻（通用搜索引擎），要么太碎（散落在各处的内部系统）。执法者需要的，是一个能理解执法语境、能即时回应、能随身携带的助手。

试错：从小程序到H5的两次起步

最开始做的是小程序。依托微信生态，不用安装，点开就能用，分发门槛极低。但很快发现了问题：小程序的网络请求有严格的域名校验，流式SSE对话被微信中间层拦截，打字机效果卡顿严重，API Key也容易暴露。更关键的是，小程序的包体积限制、WebView渲染限制，让很多交互细节根本做不到位。

第二步转向了纯H5网页。一套HTML/CSS/JS，浏览器打开就能跑，前端生态完全放开，流式对话、历史记录、打字机效果都顺利实现了。但H5的短板同样明显：浏览器随时可能杀掉进程，历史对话容易丢失；无法后台运行，收到消息没有推送；在不同手机的浏览器里，输入框适配、键盘弹出行为千差万别，用户体验碎片化严重。

走到这里我才明白：小程序太"重"规则，H5太"轻"能力。要真正把体验做到极致，最终必须走向独立APP。

抉择：用WebView做一款轻量APP

摆在面前的技术路线有三条：纯原生开发（Kotlin/Java）性能好但迭代慢，跨平台框架（Flutter/React Native）生态成熟但包体积大，而我需要的是一个能快速迭代、前端生态丰富、单代码库就能跑起来的方案。

WebView 是最自然的选择。一套H5代码跑在Android WebView里，用JavascriptInterface桥接原生能力：前端负责界面和交互，原生负责网络请求和设备能力，API Key留在原生层不暴露给前端，安全有保障。一个WebView，一个本地HTML文件，一个OkHttp SSE连接，一个JS Bridge——核心逻辑不超过五百行代码。我甚至天真地以为，一个周末就能搞定。

然后我掉进了坑里。

至暗时刻：两个月迭代了十四个版本

两个最不起眼的问题，困住了我整整两个月：状态栏和TopBar之间总有一条消不掉的空白，键盘弹出后输入框被盖住，用户看不到自己打字的内容。这两个问题听起来微不足道，却是移动端WebView开发最经典的噩梦。

十四次失败。每一次都觉得"这次一定行"，每一次都在测试截图前败下阵来。有几个晚上我几乎想放弃：一个布局问题，值得花两个月吗？但每次打开手机看到那条空白、看到被键盘盖住的输入框，我就知道：如果用户连顺畅打字都做不到，这个APP什么都不是。

顿悟：一行代码解决两个月的难题

第十四次失败后，我停下来把所有方案列成表格逐一复盘，突然发现了一个规律：之前的每一次尝试，都在"手动干预"安全区域和键盘高度——用JS注入、用CSS变量、用原生检测——但Android系统本身早就有一套完善的fitsSystemWindows机制，只是我一直没有用对地方。

真正的问题根源：开启edge-to-edge沉浸式模式后，直接setContentView(webView)时，WebView的fitsSystemWindows属性默认不生效，系统不会自动给它加状态栏padding，导致TopBar顶到了状态栏下面。

// 之前错误的写法 ❌
val webView = WebView(context)
setContentView(webView)

// 最终正确的写法 ✅
val container = FrameLayout(context)
container.fitsSystemWindows = true
container.addView(webView)
setContentView(container)

一行代码。两个月。十四个版本。无数次截图、卸载、重启、再安装。当v1.7.1-C在手机上第一次完美运行——TopBar紧贴状态栏，键盘弹出后输入框稳稳浮在上方——那一刻的释然，比任何成就感都来得真实。

成型：警律通最终的样子

布局问题解决后，一切都水到渠成：OkHttp SSE实现的流式对话丝滑流畅，JS Bridge把API Key安全留在原生层，localStorage存储历史对话，侧边栏一拉即出。警律通最终长成了一个安静而专业的对话界面：打开APP，顶栏是"警律通 · 智能执法办案助手"，中间是对话流，底部是输入框，没有花哨的动画，没有多余的按钮。