Azure Functions、.NET LTS、In-process / Isolated Worker 备忘 Q&A
Copyright Notice: This article is an original work licensed under the CC 4.0 BY-NC-ND license.
If you wish to repost this article, please include the original source link and this copyright notice.
Source link: https://v2know.com/article/1308
Q1. 我想用 Azure Functions，有没有完全不受支持时间限制的方案？
没有。
Azure Functions Runtime、.NET、Node.js、Python、Java 这些都有自己的生命周期。
所以不存在“选一次，以后永远不用管”的技术栈。
现实做法是：
选择当前主流版本
+
选择 LTS 版本
+
使用未来推荐的执行模型
+
把业务逻辑和 Function 入口分离
也就是尽量减少未来升级成本，而不是幻想永远不用升级。
Q2. 现在新项目推荐用什么组合？
目前更推荐：
Azure Functions v4
.NET 10 LTS
Isolated Worker Model
原因是：
.NET 8 LTS 支持到 2026年11月10日，而 .NET 10 LTS 支持到 2028年11月14日。(Microsoft Learn)
所以如果是新项目，并且不想很快又遇到支持期限问题，优先考虑 .NET 10 LTS 更合理。
Q3. Azure Functions v4 本身有没有支持时间？
有生命周期，但目前 Azure Functions v4 是当前主流支持版本。
需要注意的是，Azure Functions Runtime v1 会在 2026年9月14日 结束支持，v2 / v3 已经在 2022年12月13日 结束扩展支持，所以现在新项目基本应选 v4。(Microsoft Learn)
不过，v4 也不是永久存在。
以后如果出现 v5，也可能需要迁移。
所以要理解成：
Azure Functions v4 = 当前推荐版本
不是永久免维护版本
Q4. .NET In-process model 是什么？
In-process model 是旧式 Azure Functions .NET 执行方式。
简单说：
你的函数代码
和
Azure Functions Host
运行在同一个进程里
优点是写法传统，老资料多。
缺点是它和 Azure Functions Host 绑得比较紧，.NET 版本自由度较低，而且生命周期已经进入倒计时。
Microsoft 文档明确说明，.NET in-process model 会在 2026年11月10日结束支持。(Microsoft Learn)
所以新项目不建议再选它。
Q5. .NET Isolated Worker Model 是什么？
Isolated Worker Model 是现在更推荐的 .NET Azure Functions 执行方式。
简单说：
Azure Functions Host
和
你的 .NET 函数程序
分开运行在不同进程里
它的好处是：
.NET 版本选择更灵活
更接近普通 .NET / ASP.NET Core 的写法
依赖注入、配置、日志更自然
未来支持方向更明确
也就是说，它更像是：
一个普通 .NET 程序
只是入口挂在 Azure Functions 上
Q6. In-process 和 Isolated Worker 最大区别是什么？
一句话：
In-process = 函数代码寄生在 Azure Functions Host 里面
Isolated Worker = 函数代码作为独立 .NET Worker 跑
对比一下：
| 项目 | In-process | Isolated Worker |
|---|---|---|
| 运行方式 | 和 Functions Host 同进程 | 单独 .NET Worker 进程 |
| 支持前景 | 2026/11/10 结束支持 | 未来主流方向 |
| .NET 版本自由度 | 较低 | 较高 |
| 写法风格 | 旧 Azure Functions 风格 | 更接近现代 .NET |
| 新项目推荐度 | 不推荐 | 推荐 |
Q7. 那 .NET 8 LTS 还能不能用？
能用，但要看场景。
.NET 8 LTS 支持到 2026年11月10日。(Microsoft Learn)
如果项目已经在 .NET 8 上，短期内可以继续。
但如果是现在新建项目，又希望减少几年内升级压力，那更推荐 .NET 10 LTS。
简单判断：
已有项目：.NET 8 可以继续，但要规划升级
新项目：优先 .NET 10 LTS
Q8. 我最应该避免什么组合？
最应该避免：
Azure Functions v4
+
.NET 8
+
In-process model
原因是：
.NET 8 支持到 2026/11/10
In-process model 也在 2026/11/10 结束支持
这等于你刚做完不久，就已经站在迁移倒计时上了。
Q9. 如果用于 Power Apps 调用后端 API，推荐结构是什么？
如果架构是：
Power Apps
↓
Azure Functions API
↓
Azure SQL / PostgreSQL / Dataverse
推荐这样拆：
BKSystem.Functions
BKSystem.Core
BKSystem.Data
含义是：
BKSystem.Functions
只负责 HTTP API 入口、参数接收、返回结果
BKSystem.Core
放业务逻辑
BKSystem.Data
放数据库访问
这样以后升级 Azure Functions Runtime 或 .NET 版本时，主要改 Functions 项目。
业务逻辑不会全部混在 Function 里，迁移成本会低很多。
Q10. 最终结论是什么？
备忘用一句话：
新项目用 Azure Functions v4 + .NET 10 LTS + Isolated Worker。
不要新建 .NET In-process。
不要幻想完全没有支持期限，只能通过结构设计降低未来升级成本。
更具体一点：
推荐：
Azure Functions v4
.NET 10 LTS
Isolated Worker
业务逻辑放 Core class library
不推荐：
Azure Functions v4
.NET 8
In-process
所有业务逻辑直接写在 Function 里面
这才是比较稳的路线。
This article was last edited at