1. 先说清楚为什么 AI 生成的 TS 源码不能直接丢给 IIS1.1 这个需求是怎么来的最近在 Windows 服务器上折腾一个内部工具站点顺手用 Google AI Studio 生成了一段带交互逻辑的前端源码拿到手是标准的 TypeScript 项目结构src目录、tsconfig.json、package.json一应俱全。我的第一反应是——直接把这堆源码丢到 IIS 的站点目录里浏览器一访问不就能跑了吗这个想法很快就翻车了。翻车的原因其实很简单IIS 本质上是一个静态文件服务器加应用宿主它负责把磁盘上的文件通过 HTTP 协议交给客户端。对于.html、.css、.js这类静态资源它处理得很干净但 TypeScript 这类源码IIS 既不认识也没有能力去编译。浏览器更不认识.ts文件——你在地址栏输入一个指向.ts文件的 URL浏览器大概率会尝试把它下载下来而不是执行里面的逻辑。所以“在 IIS 上直接运行 Google AI Studio 生成的 TS 程序”这件事真正的技术路径应该是拿到 TS 源码 - 本地编译打包成纯静态资源 - 把静态资源部署到 IIS。这中间省不掉构建这一步谁想省谁就会被 404、样式丢失、路由刷新白屏这些问题教做人。1.2 TS 源码到浏览器之间隔着一道编译工序TypeScript 是微软推出的 JavaScript 超集它给 JS 加了类型系统、接口、泛型这些编译期工具。浏览器从来没打算直接执行 TS它只认 ECMAScript 标准的 JS。所以 TS 源码在被浏览器使用之前必须经过一次编译更准确地说是转译把类型注解全部擦除把enum、装饰器、命名空间这类 TS 特有语法转换成普通 JS。Google AI Studio 生成的项目大多数是基于 Vite 或者类似构建工具搭建的源码里会有src/main.ts、src/App.tsx之类的入口文件。启动构建命令后工具链会把整个项目的 TS 源码、CSS、静态资源一起打包最终在一个dist目录下生成纯静态文件。这些文件才是真正能交给 IIS 的交付物。我把这个过程类比成“做菜”TS 源码是食材构建工具是灶台dist目录是出锅的菜。IIS 只是服务员它负责把菜端到客人面前你不能把一堆生肉直接交给服务员。1.3 “直接运行”的正确理解方式网上搜“IIS 直接运行”相关的内容多半会搜到 PHP、ASP.NET 这类服务端程序的部署教程。前端静态部署完全是另一套玩法。经过这次实操我总结出的正确理解方式是Google AI Studio 负责生成代码不负责运行代码。它是 AI 编程助手不是 Web 服务器。TS 源码在开发机上完成编译。部署到 IIS 的是编译产物不是源码。IIS 的角色是静态资源托管。它把dist目录映射成一个网站用户访问域名或端口时IIS 返回index.html浏览器的 JS 再接管页面渲染。如果你拿到了一个 TS 项目别想着怎么让 IIS 去“解释”TS正确的姿势永远是“先构建后托管”。这个认知打通了后面所有步骤都顺了。2. 开工前的环境准备IIS 和前端构建链一样都不能少2.1 在 Windows 上把 IIS 装好我这次用的是 Windows Server 2019Win10/Win11 家庭版也能装只是系统组件叫法略有差异。安装 IIS 的路径是控制面板 - 程序 - 启用或关闭 Windows 功能在列表里找到“Internet Information Services”。这里建议不要只勾最外层的复选框要把子项也展开。几个容易出厂默认没勾、但后面一定会用到的子项常见 HTTP 功能- 静态内容、默认文档、HTTP 错误运行状况和诊断- HTTP 日志排查访问问题全靠它性能功能- 静态内容压缩JS/CSS 体积能小不少管理工具- IIS 管理控制台这个必须勾不然后面没法图形化操作装完以后打开浏览器访问http://localhost如果看到 IIS 默认的欢迎页说明服务已经起来了。这里有个小提醒IIS 默认 80 端口会占用如果你机器上还装了别的 Web 服务比如某些软件自带的 nginx可能端口冲突装之前先确认 80 端口是空闲的。2.2 准备 TypeScript 编译链源码侧的准备工作反而比 IIS 安装更琐碎。需要确认开发机上有没有 Node.js因为 Vite 和 TypeScript 编译器都是跑在 Node 环境里的。打开命令行敲node -v和npm -v能正常输出版本号就可以继续。如果没装去 Node.js 官网下 LTS 版本一路下一步装完即可。这里不建议用太老的 Node 版本Vite 5 以上对 Node 版本有硬性要求18版本不够会直接报错。装完 Node 之后TypeScript 编译器不一定需要全局安装因为项目自身的node_modules里会带。只要项目里有package.json执行npm install就会把依赖全部拉下来构建时调用的tsc和vite都从项目本地依赖里读取全局环境保持干净反而更好维护。2.3 从 Google AI Studio 导出到本地项目不同 AI 平台的导出方式不太一样Google AI Studio 通常会给出一个可复制的项目结构或者允许直接下载压缩包。实操中我遇到的常见形态有两种单文件形态所有代码挤在一个main.ts里没有package.json这种不属于完整工程需要手动补一个package.json和tsconfig.json才能构建。工程形态自带package.json、vite.config.ts、index.html、src/目录下载解压后基本就能跑。拿到工程形态的项目后我建议先把整个目录放在一个不含中文和空格的路径下比如D:\projects\ai-tool。Windows Node 工具链对中文路径的支持时好时坏尤其是 Vite 在构建时处理静态资源路径一旦路径里有中文很容易出现诡异的编码问题。这个坑我在后面还会再提一次先在这里埋个伏笔。3. 从 TS 源码到可部署产物的完整流程3.1 还原依赖并确认项目的默认命令Google AI Studio 生成的工程一般会在README或代码注释里写明使用方式但为了稳妥还是打开package.json看一遍scripts字段。一个典型的 Vite TS 项目的scripts长这样{ scripts: { dev: vite, build: tsc vite build, preview: vite preview } }这里的关键是build命令。它会先执行tsc做类型检查再执行vite build做打包。如果 AI 生成的代码里有类型错误tsc这一步会直接中断构建失败。在项目根目录打开命令行执行npm install这一步会下载所有依赖耗时取决于网络和包数量一般在 1 到 5 分钟之间。如果node_modules已经存在比如从压缩包里有带可以跳过这一步直接构建。依赖装完以后我习惯先跑一次npm run build探探路。第一次构建如果报错大多数情况是类型问题或者缺依赖看错误信息逐个解决就行。3.2 构建产物的标准动作构建命令执行完毕后项目根目录下会出现一个dist文件夹Vite 的默认输出目录。这个文件夹就是最终的部署单元。为了确认构建结果是否完整我会检查dist目录下的核心文件index.html整个应用的入口引用了编译后的 JS 和 CSSassets/目录存放 JS、CSS、图片、字体等经过 hash 命名的静态文件可能会有favicon.ico、public目录下的其他静态内容这里有一个小知识assets目录下 JS 文件名往往带着一长串 hash比如index-abc12345.js。这个 hash 是内容指纹只要源码变了构建产物文件名就会变。好处是浏览器缓存不会串坏处是你得习惯“每次部署后资源名都不一样”。3.3 检查产物目录里的关键文件构建完成不等于万事大吉我每次都要手动检查dist/index.html里的引用路径。用记事本打开这个文件重点看script和link标签的src和hrefscript typemodule crossorigin src/assets/index-abc12345.js/script link relstylesheet crossorigin href/assets/index-abc12345.css注意这里的/assets/...是绝对路径。也就是说浏览器访问站点后会向服务器的/assets/目录发起请求。如果 IIS 站点的物理路径没有把dist作为根目录或者assets文件夹没被正确映射页面就会一直转圈控制台报一堆 404。另外还要确认构建配置里的base选项。Vite 默认的base是/对应站点根目录部署。如果这个站点不是部署在根路径而是想放在http://ip:port/somepath/这种子路径下就需要在vite.config.ts里设置base: ./否则所有资源都会按根路径请求部署在子目录时全部 404。我用默认根路径部署所以这步暂时不需要改。4. IIS 站点配置与静态托管实操4.1 创建站点和绑定端口打开 IIS 管理器在左侧“连接”面板右键点击“网站”选择“添加网站”。这里有几个关键字段需要填网站名称随便写建议和项目名一致方便识别物理路径选择刚才的dist目录端口如果 80 没被占用可以直接用 80如果只是内部测试用8080之类的高位端口更省心确定之后站点就会出现在列表里。右键点击站点选择“启动”一个静态站点就算立起来了。这里我遇到过一个小插曲添加站点时如果不小心把端口填成了已被占用的端口IIS 会提示端口冲突站点无法启动。这时候换一个端口即可。绑定 IP 地址一般选“全部未分配”如果只想本机访问可以选127.0.0.1。4.2 默认文档、物理路径与目录权限一个很容易被忽略的配置是“默认文档”。IIS 的默认文档列表中默认会有Default.htm、Default.asp、index.htm等但不一定包含index.html。这就导致一个现象你访问http://localhost:8080时IIS 不知道默认该返回哪个文件直接给你一个 403 或者目录列表。解决办法是在站点主页找到“默认文档”点击右侧操作栏的“添加”输入index.html然后把它移动到列表最顶部。这一步做完访问根路径就能直接命中 Vite 生成的应用入口。物理路径的权限也要留意。IIS 进程是以IIS_IUSRS和IUSR身份运行的如果dist目录所在的磁盘分区权限比较严格比如放在系统盘的某个受限目录下客户端请求静态资源时可能得到 401 或 403 错误。解决办法是右键dist目录 - 属性 - 安全添加IIS_IUSRS用户的“读取和执行”权限。一般放在非系统盘、路径又简单的目录权限问题比较少但为了保险我每次都顺手检查一遍。4.3 首次访问验证站点配置好以后先在服务器本机打开浏览器访问http://localhost:端口。如果页面正常渲染说明基础链路通了。这时候再从局域网内另一台电脑用http://服务器IP:端口访问验证一下网络层的连通性。如果本机能开、局域网其他机器打不开大概率是 Windows 防火墙拦住了端口。到“Windows Defender 防火墙”的“高级设置”里添加入站规则放行对应端口。添加规则时注意勾选允许“专用”网络否则笔记本这种双网络环境还是会拦截。首次访问验证时打开浏览器开发者工具F12的 Network 面板刷一次页面重点看有没有红色 404 请求。我有一次部署完页面能打开但样式全乱一查 Network 面板CSS 文件 404因为 MIME 类型没配好被 IIS 拦了。这类问题在下一节细说。5. IIS 静态部署最常踩的 5 个坑5.1 样式全丢了MIME 类型缺失IIS 对未知文件类型默认是不返回的它会报 404.3 错误。Vite 构建产物里最常见的几个文件类型是.js、.css、.json、.svg、.woff2。旧版 IIS 对.js和.css的支持没问题但.svg、.woff2这类较新的媒体类型默认行为就不好说。我当时遇到的情况是页面 HTML 出来了但.css请求返回 404.3控制台直接报错“Failed to load resource”。排查后发现 IIS 的静态文件 MIME 映射里没有.css类型部分精简版系统会有这个问题。解决办法是在 IIS 管理器里双击“MIME 类型”点击“添加”逐个补齐扩展名MIME 类型.jsapplication/javascript.csstext/css.jsonapplication/json.svgimage/svgxml.wofffont/woff.woff2font/woff2.webpimage/webp这里有一个小坑某些环境里.js的 MIME 类型被错误地配成了text/plain浏览器虽然能下载文件但在严格模式下会拦截执行。如果页面白屏且控制台提示 MIME 类型不匹配优先检查这一项。5.2 刷新就 404history 路由没有重写如果 AI 生成的是一个单页应用SPA并且用到了前端路由的 history 模式那么部署后会出现一个经典问题从首页点进去正常一刷新子页面就 404。原因不难理解。前端路由的 URL 是虚拟的比如http://server/app/user浏览器向服务器请求这个路径时IIS 去物理目录找app/user当然找不到。解决方案是配置 URL 重写规则让所有请求都回退到index.html由前端路由器自己判断该渲染哪个组件。在dist目录下新建一个web.config内容如下?xml version1.0 encodingUTF-8? configuration system.webServer rewrite rules rule nameSPA Routes stopProcessingtrue match url.* / conditions logicalGroupingMatchAll add input{REQUEST_FILENAME} matchTypeIsFile negatetrue / add input{REQUEST_FILENAME} matchTypeIsDirectory negatetrue / /conditions action typeRewrite url/index.html / /rule /rules /rewrite /system.webServer /configuration这套配置的含义是当请求的路径既不是真实文件也不是真实目录时一律重写到index.html。注意使用这个规则的前提是 IIS 装了 URL Rewrite 模块没装的话去官网下载安装几分钟的事。如果你不想装模块也可以用自定义错误页的方式曲线救国但效率低不推荐。5.3 外网打不开防火墙拦了端口这是 IIS 部署最让人血压升高的问题之一。本机访问http://localhost:8080一切正常换到局域网甚至公网就是死活打不开。大多数情况就是防火墙入站规则没放行对应端口。以放行8080端口为例命令行一行搞定netsh advfirewall firewall add rule nameWeb 8080 dirin actionallow protocolTCP localport8080如果是云服务器还要去云厂商的安全组控制台放行端口。这一步和 IIS 本身没关系但很多人排查半天最后发现是安全组规则忘了加白白浪费半小时。另外有一个细节如果服务器 IPv6 和 IPv4 都启用了客户端用 IPv4 地址访问而监听只绑在[::]上也有可能出现访问异常。这时候在 IIS 站点绑定里把 IP 地址设为“全部未分配”避免只绑了某一个协议栈。5.4 图片字体加载不出来路径前缀问题页面能打开功能也正常但图片裂了、字体图标变成方框这类问题多数是资源路径不匹配。前面提到过 Vite 的base配置决定构建时资源引用的根路径。如果站点部署在根路径base: /没问题如果部署在子路径而base没改那index.html里引用的/assets/...会跑到站点根路径去请求资源。因为站点本身就是子路径应用根路径下没有assets于是 404。解决办法有两种如果允许调整部署位置最简单把站点直接绑到根路径不用子路径。如果必须部署在子路径改vite.config.ts把base设为./重新构建让index.html里的资源引用变成相对路径。我个人更推荐第一种。子路径部署在 IIS 上还要额外处理虚拟目录、URL 重写等问题复杂度翻倍能避免就避免。5.5 缓存坑改了代码不生效AI 生成的代码往往是反复迭代的改了逻辑、重新构建、部署到 IIS 后浏览器里看到的还是旧界面十有八九是缓存。第一次遇到这个问题时我还以为部署错了目录把dist翻了个底朝天。后来才发现是浏览器缓存了旧的 JS 文件。Vite 静态资源的名字带 hash新构建的文件名不一样浏览器理论上会请求新文件但index.html本身可能被缓存了浏览器拿到旧的index.html自然加载的还是旧的 JS。解决思路有两条开发/测试阶段F12 打开开发者工具Network 面板勾选 Disable cache同时强制刷新CtrlF5。IIS 侧给index.html加一个不缓存的响应头在站点根目录的web.config里加configuration system.webServer staticContent clientCache cacheControlModeDisableCache / /staticContent /system.webServer /configuration注意这个配置会对所有静态文件生效生产环境如果想保留缓存可以只对index.html做 location 级别的配置这里不展开属于进阶玩法。6. 常见问题与排查技巧实录6.1 问题与排查速查表现象最常见的根因解决动作访问站点显示 403.14 或目录列表默认文档里没有 index.html添加 index.html 到默认文档列表页面白屏控制台报 MIME 类型错误缺少 .js/.css 的 MIME 映射在 IIS 的 MIME 类型中补充 .js/.css刷新子路由 404没有配置 URL 重写规则在 web.config 里配置 SPA 回退规则本机能开其他机器打不开Windows 防火墙或云安全组未放行端口添加防火墙入站规则检查安全组样式渲染正常图片全部加载失败资源路径使用了绝对路径或 base 配错调整 Vite 的 base 配置重新构建改完代码重新部署页面还是旧内容浏览器或 IIS 静态缓存强制刷新或关闭 index.html 缓存访问时提示 401 未授权站点物理路径缺少 IIS_IUSRS 读取权限给目录添加 IIS_IUSRS 读取权限端口被占用站点启动失败其他服务占用了绑定的端口更换端口或停用占用端口的服务npm install 后构建报错Node 版本过旧或依赖冲突升级 Node 到 18删除 node_modules 重装访问 .json 接口数据返回 404IIS 没有 .json 的 MIME 类型添加 .json - application/json 映射这张表我贴在工位上后续每次部署前先对着过一遍能省掉至少一半的报错。6.2 几个排查思路遇到问题时我习惯按“网络层 - 服务层 - 应用层”的顺序排查这个顺序能帮你快速缩小范围。网络层先确认本机localhost能不能访问。不能访问问题在 IIS 服务本身或端口绑定能访问但局域网打不开问题在防火墙或 IP 绑定。用telnet 服务器IP 端口或者 PowerShell 的Test-NetConnection -ComputerName IP -Port 端口快速验证端口通不通。服务层看 IIS 管理器里站点状态是否为“已启动”。如果状态正常但还是打不开翻一下C:\inetpub\logs\LogFiles下的访问日志看请求是到达了 IIS 却没有响应还是根本没到 IIS。如果日志里根本找不到你的请求说明请求在网络层就被拦截了。应用层能拿到 HTML 但页面报错就打开 F12 控制台看具体是哪个资源加载失败、接口返回什么状态码。这一步能定位到 90% 的前端静态部署问题。这里想特别提一个容易忽略的点IIS 的“错误页”功能默认会把详细错误信息隐藏只显示“500 - 内部服务器错误”这种模糊信息。排查时可以在站点“错误页”里选择“详细错误”这样浏览器会直接展示具体的错误模块和代码定位问题快很多。排查完记得改回来不然生产环境会把内部路径暴露给用户。6.3 最后想说的几件事整条链路跑通之后回头看最大的收获并不是掌握了哪个具体命令而是建立了一个清晰的认知AI 生成代码只是起点工程化处理和部署优化才是真正让你“能用”的最后一公里。Google AI Studio 能帮你写代码但写出来的代码从“能运行”到“在特定服务器上稳定运行”中间还有大量环境适配、路径规划、缓存策略的工作。对于预算有限、又不想引入太重的前端工程化体系的小团队IIS 静态托管这套组合足够应付大多数内部工具站、展示页、原型验证的场景。它不需要常驻 Node 服务不需要配置反向代理只要 Windows 服务器上有 IIS把构建产物放上去就能跑维护成本很低。如果你想在这个基础之上继续扩展可以考虑几个方向一是配合webfont和 Gzip 压缩减少首屏体积二是用 Nginx 替代 IIS 时把重写规则平移到nginx.conf三是给站点配上 HTTPS 证书把内部工具的访问安全补上。每个方向单独拎出来都能写一篇实操文章但核心思路都是通的静态资源托管 合理的路径策略 正确的缓存控制。最后再分享一个小技巧因为 AI 生成的代码经常迭代我在服务器上部署时习惯建立一个releases目录每次构建产物按日期命名比如D:\sites\mytool\releases\20250114\然后在 IIS 里把站点的物理路径改到最新版本目录。一旦新版有问题把物理路径指回上一个日期目录就能秒级回滚连重新上传的功夫都省了。这个习惯救过我很多次分享给正在捣鼓同类部署的朋友应该用得上。