userConfig全局exports字段中存在profile时，dev模式和build模式会有冲突

[kingsword09]

举例：

export default defineConfig((info) => {
  const config: Bfsp.UserConfig = {
    name: "abc-w",
    exports: {
      ".": "./index.ts",
      "./a/web": "./a#web.ts",
      "./a/node": "./a#node.ts"
    },
    profiles: ["web", "node", "default"],
    packageJson: {
      license: "MIT",
      author: "BFChainer",
    },
    build: [
      {
        name: "a-web",
        exports: {
          ".": "./index.ts",
        }
      },
      {
        name: "a-node",
        exports: {
          ".": "./index.ts"
        }
      }
    ]
  };
  return config;
});

如果写成这种方式，则build模式下，会在每个build的项目的package.json中的exports字段下都加上

exports: {
  ".": {
    "import": "...",
    "require": "...",
    "types": "..."
  },
  "./a/web": {
    "import": "...",
    "require": "...",
    "types": "..."
  },
  "./a/node": {
    "import": "...",
    "require": "...",
    "types": "..."
  },
}

这种情况应该明显是有问题的，profile为web的竟然出现了node相关的，反之一样。

[kingsword09]

开发者写在全局的exports中的包含web、node平台的代码可能只是想要在dev模式下进行的开发，之后写在build中是做最后编译。也有可能在其中有包含公共的代码，希望写在全局的exports中，可以方便的不用在每个build的profile中加入。

[ryanroe]

这里本质上是针对profile做的互斥逻辑。 比如 web和node ， prod和dev这种profile，在语义上是互斥的，但是当前版本并没有完整的体系来支撑profile的这种互斥逻辑，所以可以先人为加上几个常用的互斥关系，到v3再把互斥的逻辑加入进来