Instead of copying the wallet.dat file, use File > Backup Wallet. It will guarantee the wallet is in a consistent state.
If you are using the RPC, you can use the backupwallet RPC.
Actually, not a low chance it's 50/50 I have experienced before that most of my wallet.dat file is corrupted original file is around 3kb but the copied file is 1kb or 0kb even the Core wallet is not running there is still a high chance that copied wallet.dat can be corrupted.
This is likely because BDB doesn't actually write everything to the wallet.dat file when a write completes. It instead writes it to a log file, which is later compacted into the wallet.dat file periodically. If you copy a wallet.dat file while it is in use, it is likely that you are simply missing the log files and so missing data.
For the most part, this means whenever a rescan (i.e. when you first start Core or open a wallet) is being run or when you are sending (or receiving) a transaction, it is risky to copy the wallet file because it might be in an inconsistent state.
It is always risky to copy because it writes to a log rather than to the data file.
But if Core is using write locks on the wallet file then it would prevent the file from being copied while in such a state in the first place. Maybe achow can clarify if Core write-locks the wallet files.
The wallet.dat file is not directly locked. IIRC there were problems with doing that.
If OP is using a descriptor wallet, then the database is actually a SQLite database and not BDB. There are thus much better guarantees of consistency. SQLite uses a rollback journal instead of a log, so data is only not in the data file for a short period of time (whereas in BDB it can live in the log for a very long time). Even so, if you were to copy the wallet.dat file in the middle of a write, there would still be consistency problems. Again, the best way to backup your wallet is to use the built in backup functionality as it guarantees the database is consistent before making the backup.