简介：面向VC++开发者的界面库模板包，以仿MSN风格为视觉基准，结合GardenUI实现代码与界面资源分离，提升UI开发效率与可维护性。压缩包内共224个文件，涵盖122个PNG图标素材、27个H头文件、16个CPP实现、16个XML界面描述文件，以及ICO、BMP、LIB/DLL等辅助资源，整体仅1.47MB，结构紧凑。示例工程包含MDI与SDI两种框架及DlgSample等模块，可清晰看到界面定义与逻辑实现的分层组织方式。已有237人学习该资源，适合希望快速搭建类MSN界面、或正在学习代码分离架构的VC++开发者。通过阅读示例与UI配置文件，能掌握GardenUI加载与事件响应的基本用法，并复用其中的图标与样式资源，减少重复设计工作。
1. 仿 MSN 风格模板代码分离 GardenUI 界面：这不是怀旧，是降本
如果你在前端圈混过几年，一定见过那种一眼就能认出年代感的界面：深蓝渐变标题栏、底部停靠的气泡聊天窗、未读消息跳动的数字角标。这就是“仿 MSN 风格”最典型的视觉锚点。但这次我们要做的不是单纯把旧界面“画”回来，而是在一个叫 GardenUI 的界面体系里，用模板与代码分离的方式，把这种老风格做成可复用的前端方案。GardenUI 可以理解为某套内部沉淀的 UI 资源体系，关键在于它强调整体视觉一致性和组件复用，而“仿 MSN 风格”正好是检验这套体系最合适的目标——因为 MSN 风格的视觉元素极具辨识度，从配色到布局到交互细节都有严格规律，非常适合用模板抽离的方式去管理。
为什么这个话题值得认真做？因为很多团队在还原老风格界面时，最常见的做法是把样式和结构写死在业务代码里，结果就是改一个主题色要全局搜索替换，新增一个页面要复制粘贴一整套 HTML。模板与代码分离的价值在于把界面结构、视觉表现、业务逻辑拆成三个独立层面，改样式不动结构，换数据不碰模板。这篇文章会给你一套完整的落地路径：从拆解 MSN 风格的设计语言开始，到模板分离的架构设计，再到具体的布局还原、交互实现和踩坑记录，最后给出验证方法。适合有前端基础、想提升界面复用能力、或者被老系统界面维护折腾过的开发者。
2. 拆解 MSN 风格的设计语言：先把视觉规律变成可量化参数
2.1 三个核心视觉锚点：底部停靠、气泡会话、状态色系
MSN 风格之所以让人一眼认出，靠的并不是某个单一元素，而是三组高度统一的视觉规律。第一组是底部停靠的窗口结构，聊天窗口紧贴屏幕底部，标题栏在上、消息区在中、输入区在下，宽度固定但高度可以拉伸，这种布局天然适合做多窗口平铺管理。第二组是气泡会话的呈现方式，自己发的消息靠右、蓝色气泡底，对方消息靠左、白色或浅灰气泡底，气泡之间有明显间距，时间戳和昵称用小号字悬浮在气泡外侧。第三组是状态色系，在线是绿色、离开是黄色、隐身是灰色，这些状态色贯穿整个界面，从头像边框到列表文字都有呼应。
这三组规律听起来简单，但要真正落到可复现的模板里，必须把每个元素拆成参数。我建议先建立一份设计参数表，把颜色、尺寸、圆角、间距全部定义为变量，这样后端的 GCSS 变量和模板里的 class 名就能一一对应。以 GardenUI 的规范为例，我们可以把主蓝色定为#2A7DE1，消息气泡的圆角定为12px，底部窗口的高度定为72vh等等。把这些参数固定下来，等于给“仿 MSN 风格”画了一条不可逾越的基线，之后不管做多少个页面，视觉一致性都有保障。
2.2 配色与尺寸变量：从 GCSS 变量到模板 class 的映射关系
具体到代码层面，设计参数要落到 CSS 变量里。在 GardenUI 体系中，这意味着要建立一套完整的变量命名规则。命名我习惯用--garden-msn-做前缀，这样在全局样式里看到这个前缀就能立刻识别出是仿 MSN 风格专用的变量，不会和业务样式混淆。变量体系分成四类：色板变量、尺寸变量、圆角变量、阴影变量。以下是一份可以直接抄走的变量定义：
:root { /* 色板变量：MSN 风格经典配色 */ --garden-msn-primary: #2A7DE1; /* 主蓝，用于自己消息气泡、选中态 */ --garden-msn-primary-dark: #1E5EAC; /* 深蓝，用于标题栏渐变结束色 */ --garden-msn-primary-light: #E8F1FB; /* 浅蓝，用于 hover 背景、高亮条 */ --garden-msn-bg: #F2F2F2; /* 窗口背景，整体浅灰 */ --garden-msn-bubble-self: #2A7DE1; /* 自己消息的气泡底色 */ --garden-msn-bubble-self-text: #FFFFFF; /* 自己消息的文字颜色 */ --garden-msn-bubble-other: #FFFFFF; /* 对方消息的气泡底色 */ --garden-msn-bubble-other-text: #333333; /* 对方消息文字颜色 */ --garden-msn-status-online: #4CAF50; /* 在线状态的绿色 */ --garden-msn-status-away: #FFC107; /* 离开状态的黄色 */ --garden-msn-status-offline: #9E9E9E; /* 离线状态的灰色 */ /* 尺寸变量 */ --garden-msn-win-width: 300px; /* 单窗口固定宽度 */ --garden-msn-win-height: 72vh; /* 窗口最大高度 */ --garden-msn-header-height: 36px; /* 标题栏高度 */ --garden-msn-avatar-size: 40px; /* 头像尺寸 */ /* 圆角与阴影 */ --garden-msn-radius-sm: 4px; /* 小圆角，用于标签、按钮 */ --garden-msn-radius-md: 8px; /* 中圆角，用于输入框 */ --garden-msn-radius-lg: 12px; /* 大圆角，用于消息气泡 */ --garden-msn-shadow: 0 2px 8px rgba(0, 0, 0, 0.15); /* 窗口阴影 */ }变量定义完之后，模板里的 class 命名要跟变量语义对齐。比如.gmsn-bubble--self的样式里直接引用var(--garden-msn-bubble-self)，这样后人维护时看到一个 class 名就能猜到它用的是哪个变量，改色板也不需要去模板里翻找。这个过程看起来只是命名规范，实际上是模板代码分离的第一步：把视觉表现从结构里抽出来，让模板只关心结构和语义。
2.3 模板与代码分离的架构：三层各自管什么
设计参数确定后，就要回答一个关键问题：模板、样式、逻辑三个层面各自的边界在哪里。我的做法是三层分离：结构层（HTML 模板）只负责骨架和语义，视觉层（CSS）只负责颜色尺寸和动效，行为层（JavaScript）只负责数据渲染和事件绑定。这样分离之后，一个典型的页面结构大概是这样的：HTML 里只有<div class="gmsn-window">这样的语义节点，CSS 决定它长什么样，JS 决定它显示哪些数据。
数据渲染这块，模板引擎不是必需的，原生模板字符串加简单的替换函数就够了，但如果你项目里已经有现成的模板引擎，直接用也行。关键在于约定一个渲染规则：模板里用双大括号{{ }}表示数据插值，用{{#each}}表示循环，这些规则由你自己定义的解析函数来处理。这样做的好处是，即便不引入任何第三方库，模板依然保持结构清晰，且和业务逻辑完全解耦。
逻辑层的职责是数据准备和事件绑定。数据准备指的是把后端返回的 JSON 结构整理成模板需要的格式，比如把时间戳格式化成“14:30”这种显示格式。事件绑定则是把点击、输入、键盘事件挂到模板渲染出的节点上。这里要注意一个陷阱：用模板渲染出的动态节点，不能直接绑事件，必须用事件委托，否则每次重新渲染都要重新绑定，容易造成内存泄漏和事件重复触发。后面第 5 章会详细讲这个问题。
3. 搭建 GardenUI 仿 MSN 窗口骨架：模板文件怎么组织
3.1 目录结构与模板片断划分
正式开始写代码之前，先把模板文件的目录结构定好。模板分离不是说把 HTML 全部写在一个文件里，而是按功能拆成片段，每个片段只负责一个窗口或一个区域，然后通过简单的加载函数拼装起来。我常用的目录结构是这样：
. ├── index.html ├── css/ │ ├── variables.css # 设计变量，即第 2 章的变量定义 │ ├── layout.css # 窗口布局、停靠定位 │ └── components.css # 气泡、列表项、头像等组件样式 ├── js/ │ ├── template.js # 模板解析与渲染函数 │ ├── data.js # 模拟数据，负责提供 JSON │ └── app.js # 初始化入口，事件绑定 └── templates/ ├── window.tpl.html # 聊天窗口骨架模板 ├── message.tpl.html # 单条消息气泡模板 ├── contact.tpl.html # 联系人列表项模板 └── input.tpl.html # 底部输入区域模板这样的目录结构有几个实际好处。第一是定位快，模板出问题去templates/找，样式出问题去css/找，逻辑出问题去js/找，不会出现一个文件几千行找不到北的情况。第二是复用容易，比如contact.tpl.html这个联系人列表项模板，既可以用在联系人主列表，也可以用在搜索结果的展示，改样式只需改一处。第三是后续迁移方便，如果哪天需要从原生模板换成 Vue 或者别的框架，只需要改template.js这一个渲染层，模板文件本身的结构调整很小。
值得强调的是，template.js是整套方案的发动机，它不依赖任何第三方库。如果你项目里已经有模板引擎，可以跳过这一层直接使用，但原生实现能让你更清楚模板解析的本质：所有模板引擎做的事情，本质上就是字符串替换加上一点循环和条件的处理。
3.2 手写模板解析引擎：简单到不会出错的替换逻辑
这里给出一个足够用、又不会过度设计的模板解析实现。它支持三种语法：{{ variable }}插值、{{#each list}}...{{/each}}循环、{{#if condition}}...{{else}}...{{/if}}条件判断。核心思路是用正则匹配标签，然后递归处理内部内容：
// js/template.js const TemplateEngine = { // 渲染入口：传入模板字符串和数据对象 render(template, data) { // 第一步：处理条件判断，优先于循环处理 template = this.#handleConditional(template, data); // 第二步：处理循环块 template = this.#handleLoop(template, data); // 第三步：替换剩余的普通变量插值 return this.#interpolate(template, data); }, // 处理 {{#each list}} ... {{/each}} #handleLoop(template, data) { const loopRegex = /\{\{#each\s+(\w+)\}\}([\s\S]*?)\{\{\/each\}\}/g; return template.replace(loopRegex, (match, listName, innerTemplate) => { const list = data[listName] || []; return list.map(item => { // 循环内部的插值基于当前项的数据 return this.#interpolate(innerTemplate, item); }).join(''); }); }, // 处理 {{#if condition}} ... {{else}} ... {{/if}} #handleConditional(template, data) { const ifRegex = /\{\{#if\s+([\w.]+)\}\}([\s\S]*?)(?:\{\{else\}\}([\s\S]*?))?\{\{\/if\}\}/g; return template.replace(ifRegex, (match, condPath, trueBlock, falseBlock = '') => { // 支持点路径取值，比如 user.isOnline const condValue = condPath.split('.').reduce((obj, key) => obj?.[key], data); return condValue ? trueBlock : falseBlock; }); }, // 替换 {{ variable }} / {{ user.name }} 形式 #interpolate(template, data) { const varRegex = /\{\{\s*([\w.]+)\s*\}\}/g; return template.replace(varRegex, (match, path) => { const val = path.split('.').reduce((obj, key) => obj?.[key], data); // 值为 undefined 或 null 时输出空字符串，避免页面出现 "undefined" return val ?? ''; }); } };这个模板引擎的核心逻辑其实只有三个正则替换。参数上值得注意的有两点：第一，循环和条件判断的顺序很重要，必须先处理条件，再处理循环，否则循环内部的if会被先替换掉导致循环解析失败；第二，#interpolate里对空值的处理用了??运算符，这样数据缺字段时页面不会出现一串刺眼的 “undefined”，这是实际项目中经常踩的小坑。
用这个引擎渲染一个窗口模板的调用方式也非常直接。假设我们已经通过fetch或者直接变量引用的方式拿到了模板字符串，渲染过程就是一行代码的事：
// js/app.js 中调用 const windowHtml = TemplateEngine.render(windowTpl, { contactName: '某开发者', statusText: '忙碌', messages: [ { fromSelf: true, text: '看到你发的方案了，我这边有三点反馈', time: '09:41' }, { fromSelf: false, text: '好的，你说，我记一下', time: '09:42' } ] }); document.querySelector('#app').insertAdjacentHTML('beforeend', windowHtml);3.3 窗口骨架模板：底栏定位与多窗口平铺实现
模板文件的写法，直接决定渲染出的 DOM 结构是否干净。以聊天窗口骨架window.tpl.html为例，我坚持一个原则：模板里只有结构，任何带具体文案的内容都要通过数据注入。这个窗口模板包含三块：标题栏、消息列表区、输入区域。窗口本身的定位方式是固定到底部，这就要依赖 CSS 的position: fixed加bottom: 0。
<!-- templates/window.tpl.html --> <div class="gmsn-window"><!-- templates/contact.tpl.html --> <div class="gmsn-contact">/* css/components.css */ .gmsn-contact[data-status="online"] .gmsn-avatar { border: 2px solid var(--garden-msn-status-online); } .gmsn-contact[data-status="away"] .gmsn-avatar { border: 2px solid var(--garden-msn-status-away); } .gmsn-contact[data-status="offline"] .gmsn-avatar { border: 2px solid var(--garden-msn-status-offline); } .gmsn-contact__status { font-size: 12px; color: var(--garden-msn-text-secondary); } .gmsn-contact__badge { background: var(--garden-msn-primary); border-radius: 10px; padding: 2px 8px; color: #fff; font-size: 12px; font-weight: 600; } .gmsn-contact__badge[data-unread="0"] { display: none; }这段实现里有几个细节值得琢磨。首先，>// js/app.js const appRoot = document.querySelector('#app'); appRoot.addEventListener('click', (event) => { const actionBtn = event.target.closest('[data-action]'); if (!actionBtn) return; const action = actionBtn.dataset.action; const windowEl = actionBtn.closest('.gmsn-window'); const contactEl = actionBtn.closest('.gmsn-contact'); switch (action) { case 'close': if (windowEl) windowEl.remove(); break; case 'minimize': if (windowEl) windowEl.classList.add('gmsn-window--minimized'); break; case 'send': handleSend(windowEl); break; default: break; } }); function handleSend(windowEl) { const textarea = windowEl.querySelector('.gmsn-input'); const msgText = textarea.value.trim(); if (!msgText) return; // 调用渲染函数把新消息追加到当前窗口 const messagesEl = windowEl.querySelector('.gmsn-window__messages'); const newMsgHtml = TemplateEngine.render(messageTpl, { fromSelf: true, text: msgText, time: formatTime(new Date()) }); messagesEl.insertAdjacentHTML('beforeend', newMsgHtml); textarea.value = ''; messagesEl.scrollTop = messagesEl.scrollHeight; // 滚动到底部 } function formatTime(date) { return `${String(date.getHours()).padStart(2, '0')}:${String(date.getMinutes()).padStart(2, '0')}`; }
事件委托的核心优势在于：无论模板渲染多少次、新增多少动态节点，监听器始终只有一个，挂在最外层容器上，不会有重复绑定的可能。这段代码里需要注意event.target.closest()的用法，因为用户可能点击的是按钮内部的文字节点，closest()会向上查找最近的匹配元素，所以即便点到的是文字也能正确命中>// js/state.js const AppState = { contacts: [ { id: 1, name: '某开发者', status: 'online', unread: 0 }, { id: 2, name: 'A同学', status: 'away', unread: 3 }, ], messagesByContact: { 1: [{ fromSelf: false, text: '在吗？', time: '09:00' }], 2: [{ fromSelf: true, text: '下周上线排期确认了吗', time: '10:20' }], }, activeContactId: null, }; // 全局渲染函数：窗口区域重绘或者局部更新 function reRender() { // 重新渲染联系人列表 const listWrap = document.querySelector('.gmsn-contact-list'); listWrap.innerHTML = AppState.contacts.map(c => { return TemplateEngine.render(contactTpl, c); }).join(''); // 活跃会话窗口保留，非活跃会话窗口关闭或收起 document.querySelectorAll('.gmsn-window').forEach(win => { const wid = Number(win.dataset.windowId); if (wid !== AppState.activeContactId) { win.remove(); } }); // 打开活跃联系人的会话窗口 if (AppState.activeContactId) { const contact = AppState.contacts.find(c => c.id === AppState.activeContactId); const messages = AppState.messagesByContact[AppState.activeContactId] || []; openWindow(contact, messages); } }
这种集中管理的方式，配合事件委托，可以让状态同步的逻辑维持在一条清晰的主线上：任何交互都只修改全局状态，然后调用reRender()重绘。重绘的代价在少量窗口场景下几乎可以忽略，换来的是代码可预测性的巨大提升。如果以后要接真实的 WebSocket 消息推送，只需要在推送回调里修改AppState再调用reRender()，整个界面的刷新逻辑不用改一行代码。
5. MSN 风格界面移植避坑：5 个典型翻车场景与排查路径
5.1 翻车现场一：模板字符串里的转义导致消息内容被截断
现象：渲染一条包含尖括号<html>标签文本的消息时，页面空白或者只显示了半个消息气泡。
原因：模板替换函数把<后面的内容当成了 HTML 标签解析，导致 DOM 结构错乱。本质上是数据里的特殊字符没有被转义。
解决：在#interpolate函数里统一做 HTML 转义处理，把&、<、>、"替换为实体字符。这样保证渲染出来的永远只是纯文本，不会意外产生新节点。修改后的插值函数：
#interpolate(template, data) { const varRegex = /\{\{\s*([\w.]+)\s*\}\}/g; return template.replace(varRegex, (match, path) => { const rawVal = path.split('.').reduce((obj, key) => obj?.[key], data); if (rawVal === null || rawVal === undefined) return ''; return String(rawVal) .replace(/&/g, '&') .replace(/</g, '<') .replace(/>/g, '>') .replace(/"/g, '"'); }); }这里要注意：转义函数放在插值环节，千万不要放在数据准备环节。因为同一个数据可能要用多个模板的多个字段，如果提前转义，后续做字符串处理时会遇到双重转义的麻烦。
5.2 翻车现场二：多窗口层叠顺序错乱，新窗口出现在底层
现象：打开第二个聊天窗口，它却跑到第一个窗口后面，点击也无法置顶。
原因：多个position: fixed窗口的 DOM 顺序没有变化，但 CSS 的z-index未管理，或者是 Grid 布局生效时新增节点插到了旧节点前面。在insertAdjacentHTML使用beforeend时理论上新窗口应该追加在末尾，但如果用了append到容器开头就会出现这种问题。
解决：窗口的层叠顺序完全交给 CSS 变量控制，每次打开新窗口时给窗口节点分配递增的z-index值，并显式清理旧值。最简单的做法是const zIndex = ++globalZIndex;然后赋值给新窗口的 style。同时检查#app的 grid 布局方向，确认新增节点插入位置是末尾。
5.3 翻车现场三：未读角标的圆角矩形跑成椭圆
现象：未读数字从 9 变成 10 之后，角标从正圆变成椭圆，视觉上不一致。
原因：我把角标的高度固定了，但宽度是padding撑开的，数字位数增加后宽度超过高度，圆角比例不变，自然就变成椭圆了。
解决：用min-width: 20px; height: 20px; border-radius: 10px;代替固定的width，同时加上display: inline-flex; align-items: center; justify-content: center;，让内容始终居中。另外两侧 padding 也要是对称的，只做左右 padding 的写法在这种场景下非常危险。
5.4 翻车现场四：模板循环里嵌套 condition，内层解析失效
现象：消息列表里同时对fromSelf做判断又对外层状态做判断，结果外层循环的内容被直接输出了模板语法，没有渲染成数据。
原因：前面提到过——模板引擎的解析顺序是先处理条件，再处理循环。如果循环体内部还有{{#if}}，第一次条件处理的正则匹配到的是循环体内部的if，然后循环处理时发现这段代码已经被替换过，但外层{{#each}}的包裹语法还在，导致整段失效。
解决：严格规定模板嵌套的写法。循环内部的if要短，不要在{{#each}}内部写复杂的条件嵌套，宁可把数据处理成isSelf这样的布尔字段，也不要反复嵌套。另外在#handleLoop里递归调用this.render(innerTemplate, item)而不是只调用#interpolate，这样内部的if会被递归处理，彻底解决嵌套问题。修正后的循环函数如下：
#handleLoop(template, data) { const loopRegex = /\{\{#each\s+(\w+)\}\}([\s\S]*?)\{\{\/each\}\}/g; return template.replace(loopRegex, (match, listName, innerTemplate) => { const list = data[listName] || []; return list.map(item => { return this.render(innerTemplate, item); // 递归处理内部 if }).join(''); }); }5.5 翻车现场五：状态切换后旧的 CSS 类名残留导致颜色错乱
现象：联系人从在线切成离开，头像边框颜色更新了，但文字状态颜色和昵称前的小圆点还是在线时的绿色。
原因：状态相关样式类写在了多个组件里，切换时只改了一个 class，其他组件的类名冗余了。本质上是状态驱动的样式没有统一收敛。
解决：在 GardenUI 体系里定一条铁律——状态颜色只通过根节点的一个>// js/test.js function assert(condition, message) { if (!condition) { console.error(`[FAIL] ${message}`); return false; } console.log(`[PASS] ${message}`); return true; } // 用例 1：变量插值 assert( TemplateEngine.render('<p>{{ name }}</p>', { name: '某开发者' }) === '<p>某开发者</p>', '变量插值应正确替换' ); // 用例 2：循环渲染 assert( TemplateEngine.render('{{#each list}}{{name}}{{/each}}', { list: [{ name: 'A' }, { name: 'B' }] }) === 'AB', '循环渲染应输出两条数据' ); // 用例 3：条件分支 assert( TemplateEngine.render('{{#if flag}}是{{else}}否{{/if}}', { flag: true }) === '是', '条件分支应落到 true 分支' ); // 用例 4：HTML 转义 assert( TemplateEngine.render('<div>{{content}}</div>', { content: '<script>alert(1)</script>' }) === '<div><script>alert(1)</script></div>', '特殊字符应被转义，防止注入' );
做完这两个验证之后，我对模板分离方案的判定标准就很明确了：如果换肤只改变量、回归测试全绿、排查问题时能按固定顺序定位到具体层级——这套架构就是健康的。我个人的习惯是每完成一次页面重构，就把对应的渲染用例补进test.js，时间久了这套测试就是整个前端界面的安全网，改代码时底气会足很多。希望这套思路能帮到你。
本文还有配套的精品资源，点击获取
