I have an old phone. If I let it write the SD card, sometimes it writes bad sectors. I suspect this happens when the battery is low, and because the phone fails to satisfy the standard electrical requirements of the SD card.
On a modern block device, a bad logical block might repeatedly fail to read (checksum mismatch), but be "repaired" if you successfully write new contents to it. When my phone corrupts my sd card, all I need to do is reformat the card. I don't even need to rewrite all the blocks (sometimes called "full format"). During & after a reformat, the filesystem will never read a block which it has not already written (there is never any reason for it to do so).
There are some risks of this approach. It's possible that your device is actually permanently damaged, and that problems will recur some time after formatting. If this is a concern, the safest approach is to test the device or partition somehow before formatting it. (Historically you were supposed to use
badblocks, but I'm not sure how nice it is nowadays).
If one of the data blocks of a file is bad, you might be able to recover by deleting or overwriting the file. The problem is when you have a bad block in the filesystem's internal structures. Typically filesystems do not include any code that would reset these to a default intial state. There is far too high a risk of silently losing data. Therefore the error will persist. Some filesystem checkers might ask if you want to reset the bad block though.
(Sidenote: with Linux
fsck.vfat specifically, I've had filesystems that it just gives up and says it hasn't implemented a specific type of repair. I suspect Windows version of that is a bit more comprehensive.)
Some filesystems might support restoring certain structures using a redundant copy, instead of having to reset them. FAT filesystems tend to be run with two redundant FATs, which can be used for recovery e.g. by
fsck.vfat on Linux. Ext4 tends to keep a large number of redundant "superblocks".
I understand filesystems like btrfs and ZFS can be configured to keep redundant copies of all metadata on separate devices, and be repaired while they are still running.
[expanded from this comment: Defining a state of a failed SD cards by kernel tracing? ]