从 Web 到 .NET 桌面：2016—2021 公开仓库技术轨迹

GitHub 上最早的一批仓库始于 2016 年。现在回看，它们更像一份持续多年的技术实验记录：前端页面、播放器、博客主题、Java Web、CMS、爬虫、WPF 工具和 C# 公共类都曾是阶段性重点。

2016：先把 Web 做出来

早期项目集中在 HTML、JavaScript、Bootstrap、媒体播放、Hexo 和 Java Web。FrontEndGuide、mediaelement、video.js、WebJava、WebDemo、cms 等仓库反映了当时最直接的目标：快速理解页面、组件、后台和部署之间的完整关系。

这一阶段最大的收获并不是掌握了某个框架，而是形成了“可运行结果优先”的习惯。页面必须能打开，数据必须能展示，部署后必须能访问。后来做桌面、设备和服务端系统时，这个习惯仍然有效。

2017—2019：从功能代码走向工具沉淀

Common.Utility 汇总了文件、网络、序列化、加密、图像、文档、任务和扩展方法等常用能力。它代表了一个明显变化：不再满足于完成单个功能，而是开始考虑如何让代码在下一项目中复用。

同一时期的爬虫、音乐、定时器和桌面界面项目，则让网络请求、异步任务、UI 状态和异常处理逐渐成为日常问题。

2020—2021：重点转向 C#、WPF 与 Windows

随着业务对桌面能力和系统集成的要求增加，技术重心逐步转向 C#/.NET。WPF 运行时检查、Inline Hook、桌面 UI 和各种 Windows 工具类，使关注点从“网页功能”扩展到进程、窗口、消息、系统 API 和运行时状态。

这段经历后来直接影响了几个长期方向：

1. UI 自动化不能只依赖控件表面，需要理解窗口句柄、进程边界和可访问性树。
2. Windows API 调用必须考虑权限、超时和不可中断阻塞。
3. 桌面软件的错误恢复比一次成功更重要。
4. 公共能力要从复制代码升级为有边界、有测试、可观察的组件。

今天再看这些仓库

早期仓库使用的框架和写法并不都适合今天的新项目，但它们仍然有价值：它们解释了当前技术偏好从哪里来，也提醒我避免只追逐框架名称。真正长期有效的能力仍是问题拆解、边界识别、失败处理和完整交付。