从改 MFC 标题栏，到后来做 Web / 独立开发
2016 年我刚接触 MFC，做了个基于对话框的小项目。当时最大的成就感之一，是在 OnInitDialog 里加了一行：
SetWindowText(_T("庄朋龙的博客"));编译运行，窗口标题真的变成了自己的博客名。原稿还配了两张 QQ 截图。现在看很稚嫩，但我一点都不想删——那是「我能改界面」的第一天。
早期笔记彩蛋：改标题栏到底在改什么
对桌面程序来说，标题栏是窗口身份的一部分。SetWindowText 改的是窗口文本；对话框程序在初始化阶段设置，用户一打开就看到品牌名。小小一行代码，完成的是：
- 从模板默认标题，变成自己的产品名；
- 让程序看起来「像我做的」，而不是「像示例」。
这和今天改网页 <title>、改浏览器标签文案、改 Electron/document.title，本质同一类问题：用户第一眼如何认出这是谁的产品。
跨时代小技巧对比
| 时代 | 场景 | 常见做法 |
| --- | --- | --- |
| MFC 桌面 | 对话框标题 | SetWindowText |
| 原生 Win32 | 任意窗口 | SetWindowText / 资源模板 |
| 网页 | 标签标题 | <title> / document.title |
| SPA | 路由切换标题 | 路由钩子里改 title |
| 小程序 / App | 导航栏文案 | 配置文件或运行时 API |
技术栈换了，产品问题没换：命名、信任、可识别。
从桌面开发到 Web，我走过的认知变化
- 分发方式变了。
MFC 程序要安装、要考虑环境；Web 打开链接即用。一人公司若要快速验证，Web / 独立站通常更友好。
- UI 技术迭代更快，但基本功仍在。
消息循环、控件、布局这些桌面概念，映射到今天就是事件、组件、状态。早期受过桌面训练，对「界面是状态机」更有体感。
- 我最终更在意「可交付的产品」，而不是「某门框架本身」。
MFC、后来的各种 Web 框架，都是工具。独立开发要问的是：用户任务完成了没有？能否收费或沉淀流量？
- 品牌细节值得早做。
改标题这件事看似无聊，其实是产品态度：默认文案不干活，自己的名字要出现在该出现的地方——域名、标题、邮件页脚、后台左上角。
对今天做独立产品的提醒
做 kuaisujianzhan、内容站或工具站时，我仍会检查：
- 浏览器标题是否包含可理解的产品名与页面意图；
- 分享卡片标题会不会写歪；
- 后台各个子页标题是否能让用户知道自己在哪。
这些都不需要复杂架构，却直接影响专业感。
收束
保留 MFC 那行 SetWindowText，是为了提醒自己：所有长路都从很小的「它跑起来了」开始。桌面时代改标题栏，Web 时代改 <title>，一人公司时代改的是整个产品被看见的方式。技术会过时，那种把界面变成自己作品的兴奋，不必过时。
No comments yet