空解决方案才是可控起点，应先建空解决方案再逐个添加项目；类库须选class library并统一目标框架；配置必须放在主项目中，类库通过参数接收；命名空间与目标框架需严格对齐。
先建空解决方案，再加项目最稳妥
直接新建项目时勾选“创建解决方案目录”看似省事，但一旦后续要加类库、测试项目或 C++ 动态库，就会发现命名冲突、路径混乱、启动项目错乱。空解决方案才是可控起点。
- 打开 Visual Studio → 新建项目 → 搜索
Blank Solution（模板位置：已安装 → 其他项目类型 → Visual Studio 解决方案） - 命名后确定，此时只生成
.sln文件，无任何项目 - 右键解决方案 → 添加 → 新建项目 → 逐个添加业务项目、类库、测试项目等
- 注意：第一个添加的项目默认成为启动项目，如需更换，右键项目 → 设为启动项目
类库项目必须设为 Class Library，不能选 Console 或 Web
公用工具类、实体模型、DTO 等若放在 Console App 或 ASP.NET Core Web API 项目里，其他项目引用时会连带拉入不必要的运行时依赖，编译失败或运行时报 System.IO.FileNotFoundException。
- 新建项目时明确选择
Class Library (.NET 6)或Class Library (.NET Standard 2.0)（跨框架兼容首选） - 检查项目文件
.csproj中是否含<targetframework>net6.0</targetframework>，而非net6.0-windows这类带平台后缀的 - 类库项目中不要写
Main()方法，也不要在Program.cs或Startup.cs中配置服务
配置文件只被主项目加载，类库无法读取自己的 app.config
把数据库连接字符串写在类库的 app.config 里，运行时永远读不到——ConfigurationManager.AppSettings["Conn"] 返回 null 是常态，不是代码写错了。
- 所有配置项必须统一写在**主项目**（即启动项目）的
app.config（.NET Framework）或appsettings.json（.NET Core/6+）中 - 类库中通过构造函数或方法参数接收配置值，避免硬编码或静态读取
- 若用
IConfiguration（.NET Core），主项目注入后可传递给类库服务，而不是让类库自己去new ConfigurationBuilder()
引用类库后 using 不生效？检查命名空间和目标框架对齐
明明添加了项目引用，也写了 using MyLib;，却提示“找不到类型或命名空间”，大概率是两个项目的 TargetFramework 不兼容。
- 右键类库项目 → 属性 → 目标框架，记下如
.NET 6.0；再检查引用它的项目是否同为.NET 6.0（而非.NET Framework 4.7.2） - 类库中的
namespace必须与项目名一致或显式声明，不能依赖默认命名空间设置（VS 右下角“根命名空间”可能被改过） - 引用后未自动刷新 IntelliSense？尝试关闭再重开解决方案，或执行
dotnet restore（命令行）
Blank Solution，一个用“新建项目带解决方案”，一个手动拖拽 .csproj —— 后续合并、CI 构建、调试链路全断。结构定早一步，后面少调两天。
