ASP.NET Core慈善帖子创建：照片失效、接口报415错误求排查

415-Unsupported Media Type 异常根因 #

CreatePost接口存在两处设计缺陷：

• 接口当前仅绑定PostDto复杂类型参数，ASP.NET Core默认对复杂类型参数优先启用JSON输入格式化器，仅能解析application/json格式的请求体。当使用form-data（请求头为multipart/form-data）发起请求时，框架无匹配的输入格式化器处理该格式，直接抛出415错误。
• 接口未定义接收上传文件的IFormFile类型参数，即使解决媒体类型兼容问题，框架也无法将form-data中携带的照片文件映射到接口上下文。

前端照片无法显示、控制台无报错的根因 #

创建帖子的全流程未打通照片上传链路：

• 主流程完全没有调用PhotoService.AddPhotoAsync将本地照片流转到Cloudinary服务，无法获取Cloudinary返回的可公开访问图片地址。
• 现有代码直接将未经过上传流程的postDto.Photos（无有效图片地址）赋值给Post实体，数据库存储的Photo记录不包含可渲染的URL，前端拿到空/无效的图片src自然无法正常展示；空src的裂图场景浏览器不会主动抛出控制台报错，符合观测到的现象。
• 单独编写的add-photo接口是后置照片追加逻辑，完全没有集成到创建帖子的主流程中，主流程不处理任何照片上传动作。

1. 重构CreatePost接口参数，显式声明支持的请求媒体类型，增加文件接收参数：

[HttpPost("create")]
[Consumes("multipart/form-data")] // 显式指定接口支持的媒体类型，从根源解决415报错
public async Task<ActionResult<PostDto>> CreatePost([FromForm] PostDto postDto, [FromForm] List<IFormFile> photos)
{
    if (!ModelState.IsValid) return BadRequest("Not a valid model");
    var user = await _userRepository.GetUserByUsernameAsync(User.GetUsername());

    var post = new Post
    {
        Title = postDto.Title,
        Text = postDto.Text,
        UserId = user.Id,
        Photos = new List<Photo>() // 初始化照片集合，避免空引用异常
    };

    // 循环处理上传的照片，完成Cloudinary上传
    foreach (var file in photos)
    {
        if (file.Length <= 0) continue;
        var uploadResult = await _photoService.AddPhotoAsync(file);
        if (uploadResult.Error != null) return BadRequest(uploadResult.Error.Message);
        
        post.Photos.Add(new Photo 
        {
            Url = uploadResult.SecureUrl.AbsoluteUri,
            PublicId = uploadResult.PublicId
        });
    }

    _context.Posts.Add(post);
    await _context.SaveChangesAsync();

    return new PostDto
    {
        Id = post.Id,
        Title = post.Title,
        Text = post.Text,
        UserId = post.UserId,
        Photos = _mapper.Map<List<PhotoDto>>(post.Photos)
    };
}

2. 移除原逻辑中直接赋值postDto.Photos的代码段，该部分逻辑因跳过Cloudinary上传流程，永远无法生成有效可访问的图片地址。
3. 调整PostDto结构：将Photos属性定义为返回给前端的PhotoDto集合类型，不要将其作为上传文件的接收属性，避免造成模型绑定混乱。
4. Postman测试时选择form-data请求类型，新增对应Key：title、text、photos（Key类型选择File，支持多文件选择），不要手动修改Content-Type请求头，让Postman自动生成带boundary的multipart/form-data请求头即可。

补充排查项：修复后若仍存在图片无法显示的问题，检查Cloudinary返回的SecureUrl是否正确映射到Photo实体，确保接口返回的图片地址为可公网访问的HTTPS链接，不要误用非加密的Url属性（http协议地址容易被浏览器混合内容拦截）。

内容的提问来源于stack exchange，提问作者Alessia